Re: bin/51720: tcpdump uses 100% CPU

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR bin/51720; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/51720: tcpdump uses 100% CPU
Date: Thu, 15 Dec 2016 22:52:59 +0100

 On Thu, Dec 15, 2016 at 05:35:00PM +0000, Andreas Gustafsson wrote:
 > >Environment:
 > System: NetBSD
 > Architecture: x86_64
 > Machine: amd64
 > >Description:
 > 
 > While debugging #51531, I started the following simple tcpdump command
 > at the server end of the dedicated network used for the test:
 > 
 >   tcpdump -n -i re0
 > 
 > The following day, I noticed that the tcpdump process (29583) was
 > consuming close to 100% CPU.  Running "sudo ktruss -p 29583" showed an
 > endless high-speed stream of
 > 
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  29583      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) Err#35 EAGAIN
 >  
 > The last stdout output from the tcpdump process itself was from about
 > five hours earlier, presumably because there had actually been no
 > traffic since then on the network in case.
 > 
 > After killing and restarting tcpdump, running ktruss -p against the
 > new tcpdump process, the output showed a much more reasonable once-per
 > second polling:
 > 
 >  18798      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) = 0
 >        ""
 >  18798      1 tcpdump  read(0x3, 0x7f7ff7b16000, 0x80000) = 0
 >        ""
 > 
 > So something had caused tcpdump to go into a state of continuous
 > polling, but I don't know what.  Maybe the passage of time, maybe
 > the passage of a long time without traffic, maybe something else
 > entirely.
 
 I'm seeing this with arpwatch and ndpwatch too. They also use bpf.
 Usually either they use 100% CPU right from the start, or they
 run fine for days. If they start at 100% CPU I kill and restart them
 (this can need a few tries to get them in a good state).
 
 This is with netbsd-7/i386, I've never seen this with netbsd-6
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --