[
https://issues.apache.org/jira/browse/TS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017855#comment-13017855
]
Ricky Chan commented on TS-733:
-------------------------------
I've just download 2.1.7 and compared MIME.cc and MIME.h between that and 2.0.1.
I (could be wrong but I) can't see any real code change apart from (mainly)
moving away from inkomti properitary types.
I just want to mention in my version of 2.0.1 in about line 1250 in MIME.cc
ink_release_assert(j < block_count);
This is disabled, because it get's trigger and causes an abort (I've already
reported this) and I don't believe this is fixed in 2.1.7 (speculation) based
on the content of 2.1.7 MIME.cc code isn't much different from 2.0.1. All my
reported errors seems to originate from here.
It's disabled because in my lab test it didn't affect the system although the
next_dup is pointing to something beyond it's self and therefore it could be
triggering all the subsequent headers.
I may need to add a different patch (such as don't treat it as a dup when it
points beyond it self as the RFC seems to indicate multiple tags of the same
name is valid) and may be collapsed or not. From my (very limited)
understanding of the code I believe this will be fine.
The core bug I believe is the dup code or the data it points to becomes invalid
(by another thread perhaps?).
I don't believe this (again I could be wrong) is addressed by 2.1.7.
> 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
>
>
> 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
