[Oisf-users] suricata segfault

Christophe Vandeplas christophe at vandeplas.com
Tue Oct 2 11:35:05 UTC 2012


Hoi Victor,

Just installed 1.3.1 RELEASE on a VM (ubuntu ppa van
oisf/suricata-stable) and tested with it. I got a 'killed' instead of
the segmentation fault.  As I suddenly remembered that the VM only had
1 GB of RAM I increased it to more and now it seems to run fine without
stopping/segfaulting.

So it seems I've hit a bug on v1.2.1.  (just to be clear: that was not
related to the RAM)
Sorry for the lost time and as usual thanks for the help!

Greets
Christophe

On Tue, Oct 2, 2012 at 11:51 AM, Victor Julien <lists at inliniac.net> wrote:
> Any chance you can update to 1.3.1?
>
> To find the stream/packet in which this happened you'll have to compile
> with debug symbols, add CFLAGS="-ggdb". Lowering the optimization level
> helps as well. Then in frame 3 or 4 of the bt you can print p->pcap_cnt
> which is the packet number. You can then look it up in wireshark.
>
> On 10/02/2012 11:18 AM, Christophe Vandeplas wrote:
>> Quick and small question:
>> On Suricata 1.2.1, reading a pcap, I have a segfault (see below for
>> the backtrace), if I understand it correctly the segfault is triggered
>> by traffic in the pcap.
>>
>> Do you have any advice on what I should do to be able to know what
>> packet/session if triggering this segfault? I'd love to extract it and
>> see if it can be shared.
>> (In the mean time I'm going to install a newer version of suri on
>> another box to test there)
>>
>> Thanks
>> Christophe
>>
>>
>> I am reading a pcap file (600MB) as input and have 70k rules:
>>> 2/10/2012 -- 10:55:41 - <Info> - 11 rule files processed. 70738 rules succesfully loaded, 59 rules failed
>>> 2/10/2012 -- 11:02:20 - <Info> - 72085 signatures processed. 840 are IP-only rules, 61765 are inspecting packet payload, 23015 inspect application layer, 0 are decoder event only
>>
>>
>> These are the last lines of output of Suricata (in gdb)
>> 2/10/2012 -- 11:02:35 - <Info> - stream.reassembly "toclient_chunk_size": 2560
>> [New Thread 0x7fffecff9700 (LWP 15432)]
>> [New Thread 0x7fffdf7fe700 (LWP 15433)]
>> 2/10/2012 -- 11:02:37 - <Info> - all 10 packet processing threads, 3
>> management threads initialized, engine started.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fffeeffd700 (LWP 15427)]
>> 0x0000000000433775 in SigMatchSignaturesBuildMatchArrayAddSignature ()
>>
>>
>> And here is the backtrace
>> (gdb) bt
>> #0  0x0000000000433775 in SigMatchSignaturesBuildMatchArrayAddSignature ()
>> #1  0x0000000000433dae in SigMatchSignaturesBuildMatchArraySIMD ()
>> #2  0x0000000000433eb3 in SigMatchSignaturesBuildMatchArray ()
>> #3  0x0000000000434dba in SigMatchSignatures ()
>> #4  0x0000000000435ad5 in Detect ()
>> #5  0x000000000056d2f0 in TmThreadsSlot1 ()
>> #6  0x00007ffff713fd8c in start_thread () from
>> /lib/x86_64-linux-gnu/libpthread.so.0
>> #7  0x00007ffff6a2ec2d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>> #8  0x0000000000000000 in ?? ()
>> (gdb)
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users



More information about the Oisf-users mailing list