[Oisf-devel] Segmentation fault on the latest Suricata beta

Duarte Silva duarte.silva at serializing.me
Fri Feb 7 18:20:18 UTC 2014


On Friday 07 February 2014 18:40:31 Victor Julien wrote:
> On 02/07/2014 06:37 PM, Duarte Silva wrote:
> > On Friday 07 February 2014 18:23:55 Victor Julien wrote:
> >> On 02/07/2014 05:56 PM, Duarte Silva wrote:
> >>> Hi Victor,
> >>> 
> >>> I have come to a conclusion about this. The fact that Suricata is
> >>> compiled
> >>> with stack protection and position independent code, doesn't seem to
> >>> have
> >>> anything to do with the issue in hand.
> >>> 
> >>> Actually, that specific segmentation fault did not happened again
> >>> (another
> >>> one did, I didn't compare back traces correctly :/).
> >>> 
> >>> Anyway, the new segmentation fault still happens on master, at least, up
> >>> to
> >>> commit 3967bd5517e7ab57fd82d7ce9b70dac16057b8f7. Issue opened at [1].
> >> 
> >> This is very interesting. It looks like 2 packet processing threads have
> >> the same flow. This is not supposed to happen.
> >> 
> >> You are using workers, correct?
> > 
> > Yes, I'm.
> > 
> >> In gdb, can you do:
> >> 
> >> thread 4
> >> frame 4
> >> print *p
> >> print *p->flow
> >> 
> >> and
> >> 
> >> thread 5
> >> frame 5
> >> print *p
> >> print *p->flow
> > 
> > I terminated the gdb session, I will reproduce the issue and hopefully the
> > condition repeats it self (I really need to start saving core dumps :D)
> 
> Ah, too bad.
> 
> In af-packet, are you using the cluster flow setting? What kernel
> version, NIC and driver do you have?

Reproduced the segmentation fault, the issue of the flow being present in the 
two threads happened again. Updated the issue. As I come to think about it, 
one of the following conditions or even both could be related with this:

1- In the same machine, I'm running Suricata and tcpreplay on the same 
interface. So Suricata is actually inspecting sent packets, instead of 
received.

2- We do have multiple VLAN's on the traffic, the latests commits do have fixes 
for VLAN identifier handling.

Now the information required.

# uname -a
Linux pidsma02 3.13.1-1.el6.x86_64 #1 SMP Fri Feb 7 12:01:59 UTC 2014 x86_64 
x86_64 x86_64 GNU/Linux

(You probably ain't going to like this part :P)
# ethtool -i eth1
driver: vmxnet3
version: 1.2.0.0-k-NAPI
firmware-version:
bus-info: 0000:13:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no




More information about the Oisf-devel mailing list