From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
If you start a long-running process in foreground (say, let fetchmail
run overnight, or run prelink and go away from the keyboard for some
time but return before it's done), and then try to stop the process to
get a shell back, the foreground processes apparently always stop, but
sometimes bash won't get you a shell back.  Instead, it will just sit
there waiting for the process to complete, or for its state to change.
 To wit, I started:

[root@free ~]# /etc/cron.daily/prelink

and let it run for a while.  When I came back, I tried ^Z

Nothing happened.

Opening another virtual terminal in gnome-terminal, I verified that
both the shell script and the prelink binary were in T state.  bash
was obviously not.  So I ran kill -CONT to get prelink running again.
 Then I straced bash, and bang, nothing happened again, but strace showed:

waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTSTP}], WUNTRACED) =
31027
waitpid(-1,  <unfinished ...>

and that was all.  I don't think bash should have done another
waitpid.  31027 was indeed the prelink script PID, indeed.

The fact that I've only observed this in processes that I left running
overnight in the past few days (glibc updates almost daily), or in
this case of running prelink in foreground, makes me wonder if this is
related with bug 128524.  It doesn't appear directly related with
133318, but excess calls to waitpid() seem to be a common factor.  I
didn't start any processes in background, though.

Version-Release number of selected component (if applicable):
bash-3.0-14 kernel-2.6.8-1.541

How reproducible:
Sometimes

Steps to Reproduce:
1.Start say prelink
2.Walk away from the keyboard for some time
3.Get back before it completes, and try to put it in background with ^Z

Actual Results:  You can't.  ^Z stops the process, but bash won't give
you a command-line.

Expected Results:  It should.

Additional info: