bin/55346: /bin/sh eats memory and CPU infinitely

[Eugene Grosbein]

David Schultz wrote:
> 
> On Fri, Aug 15, 2003, Eugene Grosbein wrote:
> > I think I've found a memory leak in /bin/sh.
> > There is a case when dowait() and does frees resources of
> > completed job correctly. Here is a patch:
> >
> > Index: jobs.c
> > ===================================================================
> > RCS file: /home/ncvs/src/bin/sh/jobs.c,v
> > retrieving revision 1.27.2.11
> > diff -u -r1.27.2.11 jobs.c
> > --- jobs.c    22 Jul 2003 13:11:26 -0000      1.27.2.11
> > +++ jobs.c    15 Aug 2003 13:02:23 -0000
> > @@ -960,10 +960,8 @@
> >                               if (jp->state != state) {
> >                                       TRACE(("Job %d: changing state from %d to %d\n", jp - jobtab + 1, jp->state, state));
> >                                       jp->state = state;
> > -#if JOBS
> >                                       if (done)
> > -                                             deljob(jp);
> > -#endif
> > +                                         freejob(jp);
> >                               }
> >                       }
> >               }
> 
> I don't think this is right.  This will cause jobs to be freed
> even when they shouldn't be.

Please give me an example when job should not be freed in dowait().

> The general problem you're complaining about (here and earlier) is
> that /bin/sh only checks for the termination of backgrounded
> children when it displays a prompt, and of course it doesn't do
> that in the middle of a while loop.  I don't know what the various
> standards have to say about this, but the behavior is probably
> just a bug.

Yes it is. Both bash and zsh do not behave so.