Messages in this thread | | | Date | Wed, 3 Dec 2003 15:15:09 +0000 (GMT) | From | Tigran Aivazian <> | Subject | bug in 2.4.22: process left in 'T' state. |
| |
Hi,
I just noticed a very interesting behaviour which I haven't seen before. I think it's a bug and very easily reproducible one too.
I was running in one session:
# tcpdump -i lo icmp
and in another session:
# strace -p 2117 -v
(2117 being the pid of tcpdump).
and in yet another session:
# ping -c 1 localhost
Now, after tcpdump captured the two icmp packets I waited until strace showed it blocked in the next recvfrom() system call and pressed ^C to terminate strace. It did terminate, but it left tcpdump in the 'traced' state and I couldn't do anything to kill tcpdump from within (i.e. all SIGINTs were blocked).
Re-running strace -p 2117 -c caused this:
~# strace -p 2117 -v --- SIGINT (Interrupt) ---
and in the tcpdump session:
~# tcpdump -i lo icmp tcpdump: listening on lo 15:07:09.442309 localhost.localdomain > localhost.localdomain: icmp: echo request (DF) 15:07:09.442372 localhost.localdomain > localhost.localdomain: icmp: echo reply
[1]+ Stopped tcpdump -i lo icmp ~# fg tcpdump -i lo icmp
2 packets received by filter 0 packets dropped by kernel
The two empty lines are my attempts to ^C which were ignored. Then, after I re-run strace tcpdump was stopped and then bringing it to foreground caused the SIGINT to be delivered and terminated as expected with the packet count/loss reported as normal.
Kind regards Tigran
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |