lkml.org 
[lkml]   [2003]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectbug 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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.030 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site