[Oisf-devel] 77b708=WIN?

[Victor Julien]

How is it looking so far?

I just did another git master push. It fixed a bunch of issues with the
tag handling, including a memory leak. If you're using sigs with tag in
it, please upgrade!

Cheers,
Victor


On 10/02/2011 04:20 PM, Martin Holste wrote:
> 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
>> ---------------------------------------------
>>
>>
> 
> 


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