[
https://issues.apache.org/jira/browse/TS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018043#comment-13018043
]
Ricky Chan commented on TS-733:
-------------------------------
I'm struggling to re-produce it myself at the moment! I'm not using ab but
there's no reason why that won't work, although I would have disabled
keep-alive (-k) because my threaded perl script effectively doesn't use
keep-alive. (in 2.0.1 anyway, without keep-alive it is a lot easier to crash
it).
Your purging is similar to what I am doing, except I am using curl and not
curlhead (although args look the same) and I don't bother sleeping, allowing it
to completely thrash a single CPU ;-)
For 2.1.7, I installed from source with --enable-debug --enable-layount=Debian
--with-group=nogroup --with-user=nobody (my config.layout has binaries for
Debian in /usr/bin instead of /usr/sbin which I know isn't strictly correct for
debian but it's a legacy location).
records.config is the default from the source, except port 8080 changed to port
80 (that's how I knew my 2.0.1 config was overridden and it chosen an invalid
cluster interface, even though cluster is disabled (known issue where ATS won't
start up with invalid interface even if clustering not used)).
I thought it would be good to try to crash on defaults before using my own
settings.
I'll get back if I managed to crash it again.
> 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
