Bug #324
Updated by Victor Julien over 12 years ago
Seeing this segv at shutdown every now and then. As you can see in the verdict thread t->qh is NULL, which makes me think it may be a race between the clean up phase for the receive code and the verdict thread/code? <pre> Core was generated by `/home/victor/dev/oisf/src/.libs/lt-suricata -c /etc/suricata/suricata.yaml -q 0'. Program terminated with signal 11, Segmentation fault. #0 0x0026c531 in ?? () from /usr/lib/libnetfilter_queue.so.1 (gdb) bt #0 0x0026c531 in ?? () from /usr/lib/libnetfilter_queue.so.1 #1 0x08059279 in NFQSetVerdict (p=0x91ac708) at source-nfq.c:874 #2 0x0823ac60 in TmThreadsSlotVarRun (tv=0xf1d36c8, p=0x91ac708, slot=0xf1d3740) at tm-threads.c:439 #3 0x0823ad9c in TmThreadsSlotVar (td=0xf1d36c8) at tm-threads.c:660 #4 0x00c8b96e in start_thread (arg=0xb309bb70) at pthread_create.c:300 #5 0x00725a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) f 1 #1 0x08059279 in NFQSetVerdict (p=0x91ac708) at source-nfq.c:874 874 ret = nfq_set_verdict(t->qh, p->nfq_v.id, verdict, 0, NULL); (gdb) print t $1 = (NFQQueueVars *) 0x835d820 (gdb) print t->qh $2 = (struct nfq_q_handle *) 0x0 (gdb) print p $3 = (Packet *) 0x91ac708 (gdb) print p->nfq_v.id $4 = 395382 (gdb) print verdict $5 = 1 (gdb) </pre>