[Oisf-users] Error: Decode1[31747]: segfault at 7fc3fe85cc6f ip 00000000004f0de9 sp 00007fc2fe85c230 error 4 in suricata[400000+12f000]

Peter Manev petermanev at gmail.com
Tue Aug 2 11:29:19 UTC 2011


On Tue, Aug 2, 2011 at 12:26 PM, Pablo <pablo.rincon.crespo at gmail.com>wrote:

> 2011/8/2 Peter Manev <petermanev at gmail.com>:
> >
> >
> > On Mon, Aug 1, 2011 at 11:01 PM, Fernando Ortiz <
> fernando.ortiz.f at gmail.com>
> > wrote:
> >>
> >> The problem is not at startup, It runned find for about 30 seconds until
> >> it crashed with that error. I can't reproduce the error with the same
> >> conditions of traffic right now because I was testing the IPS in
> production
> >> environment which I can only work with pass midnight (still a good
> througput
> >> to test ~200Mbps)
> >> I will try reproducing the error with stress tools in the meantime.
> Thanks
> >> in advance
> >>
> >> 2011/8/1 Peter Manev <petermanev at gmail.com>
> >>>
> >>>
> >>> On Mon, Aug 1, 2011 at 7:54 PM, Will Metcalf <
> william.metcalf at gmail.com>
> >>> wrote:
> >>>>
> >>>> looks like a bug to me. Did this produce a core dump?  If so can you
> >>>> open a ticket and paste the output of...
> >>>>
> >>>> gdb /path/to/suri/bin core.file
> >>>> bt full
> >>>>
> >>>> If you don't have a core dump and you can reproduce the bug, having a
> >>>> packet capture and running suri with
> >>>>
> >>>> ulimit -c unlimited; /path/to/suri -c suricata.yaml <other opts>
> >>>>
> >>>> to get  a coredump would be helpful.
> >>>>
> >>>> On Mon, Aug 1, 2011 at 12:43 PM, Fernando Ortiz
> >>>> <fernando.ortiz.f at gmail.com> wrote:
> >>>> > Jul 29 04:49:05 ips1 kernel: Decode1[31747]: segfault at
> 7fc3fe85cc6f
> >>>> > ip
> >>>> > 00000000004f0de9 sp 00007fc2fe85c230 error 4 in
> >>>> > suricata[400000+12f000]
> >>>> > I don't know what this error means, but it happens when I change the
> >>>> > midstream option in suricata.yaml
> >>>> > // /etc/suricata/suricata.yaml
> >>>> >   memcap: 567554432
> >>>> >   max_sessions: 550000
> >>>> >   checksum_validation: no      # reject wrong csums
> >>>> > # midstream : false
> >>>> >   midstream : true
> >>>> >   async_oneside: true
> >>>> >   inline: yes                    # no inline mode
> >>>> > Not sure if it is a bug or something misconfigured at my side.
> >>>> >
> >>>> > _______________________________________________
> >>>> > Oisf-users mailing list
> >>>> > Oisf-users at openinfosecfoundation.org
> >>>> > http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>>> >
> >>>> >
> >>>> _______________________________________________
> >>>> Oisf-users mailing list
> >>>> Oisf-users at openinfosecfoundation.org
> >>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>>
> >>>
> >>> I just made my config to exactly look like your changes - but Suri
> starts
> >>> fine, no problem.
> >>> 1.1beta2 (rev b3f7e6a)
> >>>
> >>> Thanks
> >>>
> >>>
> >>> --
> >>> Peter Manev
> >>
> >>
> >>
> >> --
> >> Fernando Ortiz
> >> Twitter: http://twitter.com/FernandOrtizF
> >>
> >>
> >> _______________________________________________
> >> Oisf-users mailing list
> >> Oisf-users at openinfosecfoundation.org
> >> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>
> > I just run it for the whole night - it didn't crash.
> > hmmm ...
> >
> >
> > --
> > Peter Manev
> >
> > _______________________________________________
> > Oisf-users mailing list
> > Oisf-users at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >
> >
>
> Hi Peter,
> as of the output of the segfault, Fernando's box is 64bit arch. What
> arch are you using? Also, consider that your traffic type and
> throughtput will not be the same as Fernando's, so it can be normal
> that it doesn't crash in your environment. I think we should wait to
> see if Fernando can reproduce it and throw some light to the
> conditions that trigger it.
>
>
> --
>
> Best regards,
>
> --
> Pablo Rincon
> @PabloForThePPL
> ------------------------------------
>

I agree.
Mine is 32 bit and it does not get anywhere near the traffic Fernando's box
gets.

Thanks

-- 
Peter Manev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110802/553aebae/attachment-0002.html>


More information about the Oisf-users mailing list