[Oisf-devel] 77b708=WIN?

[Victor Julien]

Current git master (just pushed out) fixes a memory corruption condition
where a smtp session could corrupt another session. In my case I
observed it corrupting a htp session, but I think it could have been
corrupting something else as well. Please upgrade and let me know if
things are any better for you.

Thanks!

Cheers,
Victor

On 09/30/2011 12:12 AM, Martin Holste wrote:
> Must be some kind of concurrency issue or thread locking or something.  As I
> said, the segfaults seem to only occur when under the highest load.  OTOH,
> I'm not able to reproduce my issue from a readfile, so I'm skeptical that
> it's the same one, but hopefully it's related.  Godspeed!
> 
> On Thursday, September 29, 2011, Victor Julien <victor at inliniac.net> wrote:
>> On 09/26/2011 09:22 PM, Martin Holste wrote:
>>>> How much ram does this take?
>>> About 18 GB.  I have 144, so this is no problem for me :)
>>>
>>>> You're running the git master which was last updated the 21st, so we
>>>> won't have later code that can be of influence.
>>>
>>> Ok, maybe it's running with the ac full that's done it, but I thought
>>> I had tried that before.
>>>
>>> Meanwhile, no joy on the segfaults:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 0x7fffd8ff9710 (LWP 9655)]
>>> 0x00007ffff67e4f19 in free () from /lib64/libc.so.6
>>> (gdb) bt
>>> #0  0x00007ffff67e4f19 in free () from /lib64/libc.so.6
>>> #1  0x00007ffff7bd884e in htp_tx_destroy (tx=0x7ffe200aef80) at
>>> htp_transaction.c:115
>>> #2  0x00007ffff7bd5e12 in htp_conn_destroy (conn=0x7fff5a0bfb90) at
>>> htp_connection.c:65
>>> #3  0x00007ffff7bd1112 in htp_connp_destroy_all (connp=0x7fffe746e4c0)
>>> at htp_connection_parser.c:197
>>> #4  0x000000000061f97a in HTPStateFree (state=<value optimized out>)
>>> at app-layer-htp.c:210
>>> #5  0x000000000061399b in AppLayerParserCleanupState
>>> (f=0x7ffea0459c60) at app-layer-parser.c:1240
>>> #6  0x0000000000437665 in FlowL7DataPtrFree (f=0x4007ffe200afef0) at
> flow.c:127
>>> #7  0x00000000004376cf in FlowClearMemory (f=0x7ffea0459c60,
>>> proto_map=<value optimized out>) at flow.c:1323
>>> #8  0x00000000004379a3 in FlowPrune (q=0x9441d0, ts=0x7fffd8ff8e60,
>>> try_cnt=0) at flow.c:372
>>> #9  0x000000000043a682 in FlowManagerThread (td=<value optimized out>)
>>> at flow-manager.c:170
>>> #10 0x00007ffff6f265f0 in start_thread () from /lib64/libpthread.so.0
>>> #11 0x00007ffff683f87d in clone () from /lib64/libc.so.6
>>> #12 0x0000000000000000 in ?? ()
>>>
>>
>> I'm tracing a similar and hopefully related segv condition currently.
>> It's a tricky one. It always happens in the same place in the pcap, but
>> when I extract the exact stream it's fine. Odd. Oh well, digging deeper.
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>>
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------