[Oisf-devel] 77b708=WIN?

[Martin Holste]

Ok, new code is running, but the real test won't be until midday
tomorrow when we have peak load.  I'll keep you posted.

On Sat, Oct 1, 2011 at 6:50 PM, Victor Julien <victor at inliniac.net> wrote:
> 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
> ---------------------------------------------
>
>