Guy Harris <[EMAIL PROTECTED]> writes:
> On Sun, Mar 25, 2001 at 10:51:52PM -0500, [EMAIL PROTECTED] wrote:
> > I was almost certain the following kernel oops occurred during packet
> > capture.
> > The packet received was an arp request. Kernel syslog indicated the kernel
> > received the arp request. My application captures arp packet as well.
> > The calls leading to the oops :
> > pcap_dispatch ...
> > sys_recvfrom ...
> > kfree_skbmem ...free_block.
> >
> > The call stack of the oops is below. The oops does not happen all the time.
> > However, there is a steady memory leak - Tops reported memory used by my
> > pcap application is stable at 0.3%, but system memory usage keeps going up
> > (reaching 250M used, 4M free before staying there).
> >
> > I am running Linux 2.4.0 kernel and libpcap-0.6.2. Does this look like a
> > libpcap problem or skbmem problem? Does anyone recognize the problem?
> >
> > >>EIP; c012c504 <free_block+84/d8> <=====
> > Trace; c011b77a <do_softirq+5a/88>
> > Trace; c012c82a <kfree+72/98>
> > Trace; c01d00fd <kfree_skbmem+25/80>
> > Trace; c01d024b <__kfree_skb+f3/f8>
> > Trace; c01d0d1d <skb_free_datagram+1d/24>
> > Trace; c0203a61 <packet_recvmsg+139/148>
> > Trace; c01cd441 <sock_recvmsg+41/b0>
> > Trace; c0203928 <packet_recvmsg+0/148>
> > Trace; c01ce2fd <sys_recvfrom+ad/108>
>
> It is almost certainly a kernel problem of some sort; I see little, if
> any, reason to believe it couldn't be reproduced with, say, a program
> that does the same sort of straightforward PF_PACKET-socket reading that
> libpcap does. Perhaps there's some specific things that libpcap does
> that cause a bad code path in the kernel to be followed, but the fact
> that this can happen indicates that there *is* a bad code path in the
> kernel....
>
> Without a kernel crash dump and stack trace, I can't say much about
> *why* it's happening - "free_block()" does
>
> spin_lock(&cachep->spinlock);
> __free_block(cachep, objpp, len);
> spin_unlock(&cachep->spinlock);
>
> and I don't know whether the problem is that "&cachep->spinlock" is
> bogus or if the inline "__free_block()" routine blew up because the list
> of objects passed to it to free is bogus.
This should probably be sent to lkml...
--
Yoann Vandoorselaere | C makes it easy to shoot yourself in the foot. C++ makes
MandrakeSoft | it harder, but when you do, it blows away your whole
| leg. - Bjarne Stroustrup
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
