trafficserver-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif Hedstrom (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TS-733) segfault in mime_hdr_set_accelerators_and_presence_bits
Date Tue, 12 Apr 2011 17:44:06 GMT

    [ https://issues.apache.org/jira/browse/TS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018928#comment-13018928
] 

Leif Hedstrom commented on TS-733:
----------------------------------

I finally got 2.1.7 to segfault with your method! So, at least there's some hope here to debug
this.

It takes quite a while though to reproduce (hours), but this is a step in the right direction.
As for the v2.0.1 patches, I'm a little concerned about it "fixing" the symptoms and not the
cause.

> segfault in mime_hdr_set_accelerators_and_presence_bits
> -------------------------------------------------------
>
>                 Key: TS-733
>                 URL: https://issues.apache.org/jira/browse/TS-733
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: MIME
>    Affects Versions: 2.0.1
>         Environment: X6240 AMD64 Debian Lenny (2.6.26) 64G of Ram.
>            Reporter: Ricky Chan
>              Labels: MIME, segfault
>             Fix For: 2.1.8
>
>         Attachments: disable_dup.patch-2
>
>
> We are seeing segfault and I have now put back unstripped binaries so I can get line
numbers are frame traces.
> Below is the trace, although GDB claims it's line 482, I believe it's now actually there
(a short int comparison won't crash it).  My interest is the fact that m_wks_idx is 67 which
is larger than the MAX amount of slots which I believe is 16 (0 - 15) right?
> I got this segfault 6 times this morning, and it appears from the same client too.
> I'm thinking of patching the code to make sure m_wks_idx isn't > MAX_FIELD_SLOTNUM_MAX
for now.
> #0  ink_stack_trace_dump (sighandler_frame=2) at ink_stack_trace.cc:66
> 66          fp = (void **) (*fp);
> (gdb) bt
> #0  ink_stack_trace_dump (sighandler_frame=2) at ink_stack_trace.cc:66
> #1  0x0000000000502f8a in signal_handler (sig=<value optimized out>) at signals.cc:332
> #2  <signal handler called>
> #3  mime_hdr_field_detach (mh=0x2aaab46c1298, field=0x2aaab46c1390, detach_all_dups=false)
at MIME.cc:482
> #4  0x0000000000601e8e in mime_hdr_field_delete (heap=0x2aaab46c11e0, mh=0x2aaab46c1298,
field=0x2aaab46c1390, delete_all_dups=true) at MIME.cc:1737
> #5  0x000000000056cee9 in HttpTransact::set_headers_for_cache_write (s=0x2aaaba56d8b0,
cache_info=0x2aaaba56d948, request=0x2aaaba56df90, 
>     response=0x2aaaba56dfc8) at ../../iocore/cache/../../proxy/http2/../hdrs/MIME.h:1071
> #6  0x000000000056ec29 in HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2aaaba56d8b0) at HttpTransact.cc:5270
> #7  0x000000000056ff99 in HttpTransact::handle_forward_server_connection_open (s=0x2aaaba56d8b0)
at HttpTransact.cc:4732
> #8  0x0000000000572370 in HttpTransact::handle_response_from_server (s=0x2aaaba56d8b0)
at HttpTransact.cc:4255
> #9  0x0000000000578a5d in HttpTransact::HandleResponse (s=0x2aaaba56d8b0) at HttpTransact.cc:3937
> #10 0x0000000000534485 in HttpSM::call_transact_and_set_next_state (this=0x2aaaba56d830,
f=0x2aaab46c1390) at HttpSM.cc:7190
> #11 0x0000000000549aa0 in HttpSM::state_read_server_response_header (this=0x2aaaba56d830,
event=<value optimized out>, data=0x2232e28) at HttpSM.cc:535
> #12 0x0000000000547e3b in HttpSM::main_handler (this=0x2aaaba56d830, event=100, data=0x2232e28)
at HttpSM.cc:2683
> #13 0x00000000006c19f7 in read_from_net (nh=0x2aaaac950098, vc=0x2232d50, thread=<value
optimized out>) at ../../iocore/eventsystem/I_Continuation.h:147
> #14 0x00000000006b9452 in NetHandler::mainNetEvent (this=0x2aaaac950098, event=<value
optimized out>, e=0xfa9130) at UnixNet.cc:292
> #15 0x00000000006e3614 in EThread::process_event (this=0x2aaaac94f010, e=0xfa9130, calling_code=5)
at I_Continuation.h:147
> #16 0x00000000006e3e50 in EThread::execute (this=0x2aaaac94f010) at UnixEThread.cc:249
> #17 0x00000000006e1a72 in spawn_thread_internal (a=0xf93270) at Thread.cc:85
> #18 0x00002abbb5d7efc7 in start_thread () from /lib/libpthread.so.0
> #19 0x00002abbb74f064d in clone () from /lib/libc.so.6
> #20 0x0000000000000000 in ?? ()
> (gdb) frame 3
> #3  mime_hdr_field_detach (mh=0x2aaab46c1298, field=0x2aaab46c1390, detach_all_dups=false)
at MIME.cc:482
> warning: Source file is more recent than executable.
> 482       if (field->m_wks_idx < 0)
> (gdb) p *field
> $1 = {
>   m_ptr_name = 0x19618e4 "Via1.1 AKmdrL2CacheBC10.telecom.co.nzCache-Controlmax-stale=0Via1.1
AKmdrL2CacheBC10.telecom.co.nzX-BlueCoat-ViaB8C344C089BFFBD7Client-ip210.55.215.151X-Forwarded-For210.55.215.151http10.244.132.255om"...,

>   m_ptr_value = 0x19618e7 "1.1 AKmdrL2CacheBC10.telecom.co.nzCache-Controlmax-stale=0Via1.1
AKmdrL2CacheBC10.telecom.co.nzX-BlueCoat-ViaB8C344C089BFFBD7Client-ip210.55.215.151X-Forwarded-For210.55.215.151http10.244.132.255om0yo"...,
m_next_dup = 0xffffffffb46c87f0, m_wks_idx = 67, m_len_name = 3, 
>   m_len_value = 34, m_n_v_raw_printable = 0 '\0', m_n_v_raw_printable_pad = 4 '\004',
m_readiness = 2 '\002', m_flags = 1 '\001'}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message