bug in 2.4.22: process left in 'T' state.

From: Tigran Aivazian
Date: Wed Dec 03 2003 - 10:17:19 EST


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/