Actions
Bug #1355
closedBus error when reading pcap-file on OpenBSD
Affected Versions:
Effort:
Difficulty:
Label:
Description
This is Suricata version 2.1dev (rev ff8dae3) with --enable-gccprotect on OpenBSD/amd64 5.5
No rules loaded. PCAP file attached.
/home/suricata/bin/suricata -r test-openbsd.pcap --runmode="single"
...
[32080] 30/12/2014 -- 18:07:22 - (tm-threads.c:2067) <Notice> (TmThreadWaitOnThreadInit) -- all 1 packet processing threads, 4 management threads initialized, engine started.
[32080] 30/12/2014 -- 18:07:22 - (suricata.c:2370) <Notice> (main) -- Signal Received. Stopping engine.
Bus error (core dumped)
#0 0x00000adc13ffa9cc in PacketPoolDestroy () at tmqh-packetpool.c:301
301 Packet *next_p = p->next;
(gdb) bt full
#0 0x00000adc13ffa9cc in PacketPoolDestroy () at tmqh-packetpool.c:301
next_p = (Packet *) 0x0
p = (Packet *) 0x6d69742064656966
my_pool = (PktPool *) 0xade1a380880
__func__ = "PacketPoolDestroy"
#1 0x00000adc13f5a948 in FlowForceReassembly () at flow-timeout.c:544
No locals.
#2 0x00000adc13ff5337 in main (argc=4, argv=0x7f7ffffc7a20) at suricata.c:2399
suri = {run_mode = 2, pcap_dev = '\0' <repeats 127 times>, sig_file = 0x0, sig_file_exclusive = 0, pid_filename = 0x0,
regex_arg = 0x0, keyword_info = 0x0, runmode_custom_mode = 0x7f7ffffc7b7b "single", user_name = 0x0, group_name = 0x0,
do_setuid = 0 '\0', do_setgid = 0 '\0', userid = 0, groupid = 0, delayed_detect = 0, rule_reload = 0, disabled_detect = 0,
daemon = 0, offline = 1, verbose = 0, checksum_validation = -1, start_time = {tv_sec = 1419959242, tv_usec = 67007},
log_dir = 0xade147379c0 "/home/suricata/var/log/suricata/"}
de_ctx = (DetectEngineCtx *) 0xade1ca18000
engine_retval = 0
global_de_ctx = (DetectEngineCtx *) 0x319fc0
__FUNCTION__ = "main"
__func__ = "main"
Files
Updated by Peter Manev almost 11 years ago
I can reproduce the issue on Ubuntu LTS Trusty only when using
--runmode=single
Autfp does not segfault.
Updated by Eric Leblond almost 11 years ago
This is partially linked with commit:60b50e1ca5116d6af5d9e233f3d8b6f8baba1c39. Reverting this patch fixes the problem on Linux.
For OpenBSD, the problem is triggered later in other place. It may be linked with the Thread Local Storage which is not available on this OS.
Updated by Philipp Buehler almost 11 years ago
With the reverted commit; I am now seeing this:
#0 0x000016946e0f9559 in PacketPoolGetPacket () at tmqh-packetpool.c:188
188 pool->head = p->next;
(gdb) bt full
#0 0x000016946e0f9559 in PacketPoolGetPacket () at tmqh-packetpool.c:188
p = (Packet *) 0x1
pool = (PktPool *) 0x169679cc2580
#1 0x000016946e0fa9a5 in PacketPoolDestroy () at tmqh-packetpool.c:297
p = (Packet *) 0x16966ed26290
#2 0x000016946e056625 in FlowManagerThreadDeinit (t=0x16966fe1f900, data=0x169672fa9fe0) at flow-manager.c:544
(gdb) print *pool
$1 = {head = 0x1, pending_pool = 0x169679cc25c0, pending_head = 0x0, pending_tail = 0x0, pending_count = 0, return_stack = {
mutex = 0x1696718c65c0, head = 0x0}}
If I use the malloc 'junking' feature of OpenBSD, the actual error doesnt change, but the pool data (pending pool/count)
#0 0x00001ae1317f9559 in PacketPoolGetPacket () at tmqh-packetpool.c:188
p = (Packet *) 0xd0d0d0d0d0d0d0d0
pool = (PktPool *) 0x1ae340ef4500
#1 0x00001ae1317fa9a5 in PacketPoolDestroy () at tmqh-packetpool.c:297
p = (Packet *) 0x1ae33d049290
...
(gdb) print *pool
$1 = {head = 0xd0d0d0d0d0d0d0d0, pending_pool = 0xd0d0d0d0d0d0d0d0, pending_head = 0xd0d0d0d0d0d0d0d0,
pending_tail = 0xd0d0d0d0d0d0d0d0, pending_count = 3503345872, return_stack = {mutex = 0x1ae3360fbe00,
head = 0xd0d0d0d0d0d0d0d0}}
Updated by Victor Julien almost 11 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 2.1beta3
Updated by Victor Julien almost 11 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Updated by Philipp Buehler almost 11 years ago
I can happily confirm that this resolves this issue. Thanks a lot.
Actions