Bug 151248 - Process hangs and cannot be killed
Process hangs and cannot be killed
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Don Howard
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-16 07:15 EST by Bryce
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-17 21:08:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryce 2005-03-16 07:15:49 EST
Description of problem:
Process hangs and cannot be killed

Version-Release number of selected component (if applicable):
The following problem has been seen on RHEL 3.0 U4 but it can be seen even on
RHEL 3.0 U2.

How reproducible:
[root@emerald ~]# cat foo.c 
main()
{
        while(1);
}

[root@emerald ~]# gcc foo.c

[root@emerald ~]# ./a.out &
[1] 22433

[root@emerald ~]# gdb ./a.out 22433 &
[2] 22434

[root@emerald ~]# GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found
)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /root/a.out, process 22433


[2]+  Stopped                 gdb ./a.out 22433

Now get rid of gdb but leave the a.out process
[root@emerald ~]# kill %2

[root@emerald ~]# 

[1]+  Stopped                 ./a.out
[2]   Terminated              gdb ./a.out 22433

[root@emerald ~]# ps -elf |grep 22433
0 T root     22433 22396 16  85   0 -   593 ptrace 12:05 pts/0    00:00:07 ./a.o
ut
0 S root     22439 22396  0  76   0 -  1149 pipe_w 12:06 pts/0    00:00:00 grep 
22433

Lets reattach to the process
[root@emerald ~]# gdb ./a.out 22433
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found
)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /root/a.out, process 22433


<==== GDB IS NOW COMPLETELY HUNG ===============>

<==== So from another window ===>

[root@emerald ~]# ps -elf |grep 22433
4 S root     22442 22396  0  78   0 -  1698 wait   12:07 pts/0    00:00:00 gdb
./a.out 22433
0 T root     22433 22396  4  85   0 -   593 ptrace 12:05 pts/0    00:00:07 ./a.out
0 S root     22468 22450  0  76   0 -  1331 pipe_w 12:08 pts/10   00:00:00 grep
22433

[root@emerald ~]# kill -9 22433

[root@emerald ~]# ps -elf |grep 22433
4 S root     22442 22396  0  78   0 -  1698 wait   12:07 pts/0    00:00:00 gdb
./a.out 22433
0 T root     22433 22396  3  85   0 -   593 ptrace 12:05 pts/0    00:00:07 ./a.out
0 S root     22473 22450  0  78   0 -  1111 pipe_w 12:09 pts/10   00:00:00 grep
22433


As seen above, process still lives after it has been sent a kill -9.

Essentially the kernel is not cleaning up correctly after a debugger process has
been killed. The debuggee(?) should be freed up but it is not.

Ideas? hints and yells of "don't do that then"

Phil
=--=
Comment 1 Don Howard 2005-03-17 21:08:16 EST
Hi Bryce (or is that Phil?)

In each case above the process is being ptraced when the signal is sent. 
Processes that are being ptraced don't respond to signals as usual -- the
debugger has to be notified of the event, among other things.

The process is not unkillable, it's simply stopped and ptraced.

If you send the process SIGCONT after the attached debuger has terminated, the
process will start running again. As it's no longer being ptraced, it will
respond to signals as usual again, and gdb won't block when attaching to it. 

I'm going to mark this ticket closed as not a bug.  If you have more questions
about this, feel free to re-open it and I'll try to address them.

Note You need to log in before you can comment on or make changes to this bug.