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 10 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 10 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 10 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 10 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 2.1beta3
Updated by Victor Julien almost 10 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Updated by Philipp Buehler almost 10 years ago
I can happily confirm that this resolves this issue. Thanks a lot.
Actions