[Toybox] 回复: sh: run "command &" in background, showing "jobs" or "ps" will crash

[Mingliang HU 胡明亮]

> On 5/29/23 21:33, Mingliang HU 胡明亮 wrote:
> > When running apps in the background by “xxx &”and try “jobs”or
> > “ps”sometimes, it will crash.
> >
> > It is caused by some TT.jobs arguments freed.
> 
> Hmmm, ps shouldn't care, but jobs will.
> 
> Sigh, one of my todo items is instrumenting+poisoning the heap so I can track
> lifetime rules better. (In theory the llvm ASAN stuff is doing at least part of
> that...)
> 
> > static void run_lines(void)
> >
> > …
> >
> >     // Three cases: 1) background & 2) pipeline | 3) last process in
> > pipeline ;
> >
> >     // If we ran a process and didn't pipe output, background or wait
> > for exit
> >
> >     if (pplist && TT.ff->blk->pout == -1) {
> >
> >       if (ctl && !strcmp(ctl, "&")) {
> >
> >         if (!TT.jobs.c) TT.jobcnt = 0;
> >
> >         pplist->job = ++TT.jobcnt;
> >
> >         arg_add(&TT.jobs, (void *)pplist);
> >
> > -->  pplist is freed later...
> >         if (TT.options&FLAG_i) dprintf(2, "[%u] %u\n",
> > pplist->job,pplist->pid);
> >
> >       } else {
> >
> >         toys.exitval = wait_pipeline(pplist);
> >
> >         llist_traverse(pplist, (void *)free_process);
> >
> >       }
> >
> >       pplist = 0;
> 
> Assigning zero to it there should make the free() be a NOP?
> 
> > }
> >
> >
> > Then, in show_job(), it will use random points.
> 
> I believe you, but need a reproduction sequence.

I failed to reproduce the crash on linux although the "jobs" result is not correct. 
In my used OS, I can find TT.jobs.v[arg->c++] = pplist which has an particular address. 
Then pplist = 0 soon. But TT.jobs.v[arg->c++] keeps that previous particular address. 
This particular address would be allocated by other OS process again.
Then in show_jobs(), TT.jobs.v[i]->arg.v will access wrong memory. 
"snprintf" will use "strlen" to access a quite a long "string" without "\0" and crash.
In linux PC, I guess the address was not allocated again very soon so that no crash.
> 
> Job control is only about 2/3 implemented. I had the design worked out at one
> point, but it's one of the big branches I was working on that didn't get merged.
> There's changes to "kill" and so on that go with it...
> 
> Rob