[Oisf-devel] tcp.ssn_memcap_drop

Wed Sep 21 18:24:17 UTC 2011

Just tell me when you don't these anymore, but I can't keep Suri
running for more than an hour or so under heavy traffic:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd9ffb710 (LWP 6463)]
0x00007ffff67e4f19 in free () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff67e4f19 in free () from /lib64/libc.so.6
#1  0x00007ffff7bd7b87 in htp_connp_RES_LINE (connp=0x7fff88bafa90) at
htp_response.c:578
#2  0x00007ffff7bd7349 in htp_connp_res_data (connp=0x7fff88bafa90,
timestamp=2293955480, data=0xf <Address 0xf out of bounds>,
len=140735480315311) at htp_response.c:776
#3  0x000000000061c8cd in HTPHandleResponseData (f=<value optimized
out>, htp_state=0x7fff888de280, pstate=0x7ffe1730b1a0, input=0xf
<Address 0xf out of bounds>, input_len=2286927279,
output=0x7fffae97fba0)
    at app-layer-htp.c:482
#4  0x000000000061833f in AppLayerDoParse (f=0x400000000000000,
app_layer_state=0x7fff88bafb98, parser_state=0xf, input=0x7fff884fbdaf
"\r\n\034\340\026\376\177", input_len=2, parser_idx=0, proto=1)
    at app-layer-parser.c:685
#5  0x00000000006186b8 in AppLayerParse (f=0x7ffefd0c1fe0, proto=2
'\002', flags=<value optimized out>,
    input=0x7fffd9ff9cb0 "HTTP/1.1 200 OK\r\nCache-Control:
max-age=31536000\r\nContent-Type: image/png\r\nAccept-Ranges:
bytes\r\nETag: \"80fa92311948cc1:0\", \r\nServer:
Microsoft-IIS/7.0\r\nX-Powered-By: ASP.NET\r\nS: BLUMPPSTCA03\r\nP3P:
CP"..., input_len=644) at app-layer-parser.c:898
#6  0x00000000005ef1d5 in StreamTcpReassembleAppLayer (ra_ctx=<value
optimized out>, ssn=0x7ffe4482b740, stream=0x7ffe4482b748,
p=0x28f27e0) at stream-tcp-reassemble.c:3043
#7  0x00000000005ef370 in StreamTcpReassembleHandleSegmentUpdateACK
(ra_ctx=0x7fffe80d98f0, ssn=0x7ffe4482b740, stream=0x7ffe4482b748,
p=0x28f27e0) at stream-tcp-reassemble.c:3422
#8  0x00000000005f0969 in StreamTcpReassembleHandleSegment
(tv=0x7fffdc06e1d0, ra_ctx=0x7fffe80d98f0, ssn=0x7ffe4482b740,
stream=0x7ffe4482b798, p=0x2, pq=0x7fffae97fba0) at
stream-tcp-reassemble.c:3496
#9  0x00000000005dbfae in HandleEstablishedPacketToClient (pq=<value
optimized out>, stt=<value optimized out>, p=<value optimized out>,
ssn=<value optimized out>, tv=<value optimized out>)
    at stream-tcp.c:1836
#10 StreamTcpPacketStateEstablished (pq=<value optimized out>,
stt=<value optimized out>, p=<value optimized out>, ssn=<value
optimized out>, tv=<value optimized out>) at stream-tcp.c:1990
#11 0x00000000005deace in StreamTcpPacket (tv=0x7fffdc06e1d0,
p=0x28f27e0, stt=0x7fffe80d94d0, pq=0x7fffdc06e2e8) at
stream-tcp.c:3570
#12 0x00000000005dfe7c in StreamTcp (tv=0x7fffdc06e1d0, p=0x28f27e0,
data=0x7fffe80d94d0, pq=0x7fffdc06e2e8, postpq=<value optimized out>)
at stream-tcp.c:3769
#13 0x00000000005c2618 in TmThreadsSlotVarRun (tv=0x7fffdc06e1d0,
p=0x28f27e0, slot=<value optimized out>) at tm-threads.c:439
#14 0x00000000005c2756 in TmThreadsSlotVar (td=<value optimized out>)
at tm-threads.c:660
#15 0x00007ffff6f265f0 in start_thread () from /lib64/libpthread.so.0
#16 0x00007ffff683f87d in clone () from /lib64/libc.so.6
#17 0x0000000000000000 in ?? ()

On Wed, Sep 21, 2011 at 12:10 PM, Chris Wakelin
<c.d.wakelin at reading.ac.uk> wrote:
> Sorry, I've only just started paying attention to the backtraces in this
> thread. I've got a couple of very similar ones in the last week!
>
> Looking in more detail at the src and dst addresses in Frame 7 with
> "frame 7" and "print *f" (in my case, looks like Frame 12 below), I
> found matching HTTP requests a few minutes earlier, but no apparent
> connection between those in the two cores I've kept.
>
> One thing I noticed though is that in *f, "sp" and "dp" are both 0,
> which I think might be source and destination port, which probably ought
> to be stored as part of a flow record?
>
> Best Wishes,
> Chris
>
> On 21/09/11 17:22, Martin Holste wrote:
>> This one is on a bigger box (144 GB RAM, 16 CPU) with AF_PACKET:
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0x7fffe4ff9710 (LWP 6178)]
>> 0x00007ffff679d945 in raise () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x00007ffff679d945 in raise () from /lib64/libc.so.6
>> #1  0x00007ffff679ef21 in abort () from /lib64/libc.so.6
>> #2  0x00007ffff67da8ef in __libc_message () from /lib64/libc.so.6
>> #3  0x00007ffff67e0018 in malloc_printerr () from /lib64/libc.so.6
>> #4  0x00007ffff67e4f6c in free () from /lib64/libc.so.6
>> #5  0x00007ffff7bd8880 in htp_tx_destroy (tx=0x3233d7f0) at
>> htp_transaction.c:123
>> #6  0x00007ffff7bd5e12 in htp_conn_destroy (conn=0x2cc524b0) at
>> htp_connection.c:65
>> #7  0x00007ffff7bd1112 in htp_connp_destroy_all (connp=0x3957d280) at
>> htp_connection_parser.c:197
>> #8  0x000000000061e03a in HTPStateFree (state=<value optimized out>)
>> at app-layer-htp.c:210
>> #9  0x000000000061204b in AppLayerParserCleanupState
>> (f=0x7ffe6f639b10) at app-layer-parser.c:1240
>> #10 0x0000000000437315 in FlowL7DataPtrFree (f=0x180e) at flow.c:119
>> #11 0x000000000043737f in FlowClearMemory (f=0x7ffe6f639b10,
>> proto_map=<value optimized out>) at flow.c:1406
>> #12 0x0000000000437593 in FlowPrune (q=0x942190, ts=0x7fffe4ff8e60) at
>> flow.c:336
>> #13 0x000000000043794d in FlowPruneFlowQueue (ts=<value optimized
>> out>, q=<value optimized out>) at flow.c:355
>> #14 FlowManagerThread (ts=<value optimized out>, q=<value optimized
>> out>) at flow.c:1060
>> #15 0x00007ffff6f265f0 in start_thread () from /lib64/libpthread.so.0
>> #16 0x00007ffff683f87d in clone () from /lib64/libc.so.6
>> #17 0x0000000000000000 in ?? ()
>>
>
> --
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
> Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>