[Oisf-devel] Packet Array in 1.0.x

Joel Ebrahimi jebrahimi at bivio.net
Fri Aug 20 00:02:55 UTC 2010

Sure. As I said though its not always a segfault but I can see all the
memory being used up on the system. Here is the segfault backtrace:

#0  0x10012150 in PacketEnqueue (q=0x1080eb70, p=0x2a9) at
#1  0x10012f98 in ReceivePcap (tv=0x1080ea78, p=0x10265f70,
data=0x107faef8, pq=0x1080eb10, postpq=0x1080eb70)
    at source-pcap.c:219
#2  0x10104f44 in TmThreadsSlot1 (td=0x1080ea78) at tm-threads.c:371
#3  0x0ff0d994 in start_thread () from /lib/libpthread.so.0
#4  0x0ff0d994 in start_thread () from /lib/libpthread.so.0
Previous frame inner to this frame (corrupt stack?)

Really the problem seems to get ugly in the ReceivePcap function here:

    for (cnt = 0; cnt < ptv->array_idx; cnt++) {
        Packet *pp = ptv->array[cnt];

        /* enqueue all but the first in the postpq, the first
         * pkt is handled by the tv "out handler" */
        if (cnt > 0) {
            PacketEnqueue(postpq, pp);

The problem being that array_idx keeps incrementing. So in that specific
backtrace case above array_idx is 6538 and when this section of code is
hit, once count exceeds 255 we are outside the range of memory and as
you can see from the backtrace that in the function PacketEnqueue where
p's address is wrong. 

I know the array stuff is new in the 1.0.x release and looking it over I
don't see a case that ensures it stays within the max 256 allocated or I
don't see a case where array_idx ever gets reset.

// Joel 

>-----Original Message-----
>From: Will Metcalf [mailto:william.metcalf at gmail.com]
>Sent: Thursday, August 19, 2010 4:36 PM
>To: Joel Ebrahimi
>Cc: oisf-devel at openinfosecfoundation.org
>Subject: Re: [Oisf-devel] Packet Array in 1.0.x
>Can you give us the output of a backtrace Joel?  You can send off-list
>if you so desire.
>On Thu, Aug 19, 2010 at 5:19 PM, Joel Ebrahimi <jebrahimi at bivio.net>
>> I'm seeing multiple problems with the array that was added to
>> PcapThreadVars_.
>> I either exhaust memory completely or segfault. I think they both
>> from the same issue with is that the array seems to keep filling and
>> eventually there is an access outside of PCAP_FILE_MAX_PKTS (256)
>> causes the segfaults.
>> Is the array supposed to hold a finite number of past packets ie. 256
>> whatever PCAP_FILE_MAX_PKTS is set to? If so then I suppose a modulus
>> operator or some kind of reset is needed.
>> // Joel
>> Joel Ebrahimi
>> Solutions Architect
>> Bivio Networks
>> jebrahimi at bivio.net
>> _______________________________________________
>> Oisf-devel mailing list
>> Oisf-devel at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel

More information about the Oisf-devel mailing list