Bug 183456

+++ This bug was initially created as a clone of Bug #181656 +++

Description of problem:
segfault while running a process intensive shell script

Version-Release number of selected component (if applicable):
bash-2.05b-29

How reproducible:
Once

Here is the backtrace:
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libdl.so.2...
Reading symbols from /usr/lib/debug//lib/libdl-2.3.2.so.debug...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6.1...
Reading symbols from /usr/lib/debug//lib/tls/libc-2.3.2.so.debug...done.
done.
Loaded symbols for /lib/tls/libc.so.6.1
Reading symbols from /lib/ld-linux-ia64.so.2...
Reading symbols from /usr/lib/debug//lib/ld-2.3.2.so.debug...done.
done.
Loaded symbols for /lib/ld-linux-ia64.so.2
#0  find_pipeline (pid=16856, running_only=1, jobp=0x60000fffffffa424)
   at jobs.c:893
893     {
(gdb) frame 0
#0  find_pipeline (pid=16856, running_only=1, jobp=0x60000fffffffa424)
   at jobs.c:893
893     {
(gdb) list
888     static PROCESS *
889     find_pipeline (pid, running_only, jobp)
890          pid_t pid;
891          int running_only;
892          int *jobp;         /* index into jobs list or NO_JOB */
893     {
894       int job;
895       register PROCESS *p;
896
897       /* See if this process is in the pipeline that we are building. */
(gdb) bt
#0  find_pipeline (pid=16856, running_only=1, jobp=0x60000fffffffa424)
   at jobs.c:893
#1  0x4000000000062850 in waitchld (wpid=-1, block=63080) at jobs.c:2468
#2  0x40000000000626a0 in sigchld_handler (sig=63080) at jobs.c:2398
#3  <signal handler called>
#4  waitchld (wpid=Cannot access memory at address 0xffffffffffffff70
) at jobs.c:2468
Cannot access memory at address 0xffffffffffffffe8

903           do
904             {
905               /* Return it if we found it. */
906               if (p->pid == pid)
907                 {
908                   if ((running_only && PRUNNING(p)) || (running_only == 0))
909                     return (p);
910                 }
911
912               p = p->next;
913             }
914           while (p != the_pipeline);

Looks like p != NULL isn't checked, which could be problematic if you get to the
end of the list without finding "the_pipeline".

Hand-diff:
-           while (p != the_pipeline);
+           while (p != NULL && p != the_pipeline);

-- Additional comment from kmori on 2006-02-21 21:36 EST --
Created an attachment (id=125000)
Reproduction case


-- Additional comment from kmori on 2006-02-21 21:38 EST --
Created an attachment (id=125001)
Fix patch backported from upstream