[
https://issues.apache.org/jira/browse/TS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014687#comment-13014687
]
Ricky Chan commented on TS-729:
-------------------------------
I'm currently see if I can emulate the segfault in the lab, but because I
didn't have debugging on I can't see what the request header was like prior to
crash and also with stripped binaries I lose the line numbers.
If I can *somehow* re-create in the lab, I will post line numbers and
conditions to re-create, in production system I've had to turn of insert/append
of via string for requests which should stop that part of the code running (and
hence not trigger the bug).
I also should be free to start testing with v2.1.7, with all my reported issues
as soon as I get the lab back from other testers.
Ricky
> Seg faults within HttpTransactHeaders::insert_via_header_in_request
> -------------------------------------------------------------------
>
> Key: TS-729
> URL: https://issues.apache.org/jira/browse/TS-729
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
> Affects Versions: 2.0.1
> Environment: X6240 Sun Blade (AMD64), 64G of RAM.
> Reporter: Ricky Chan
>
> Getting reports of regular seg faults on the traffic server CDN farm, in 1
> site 7 out of 10 servers have segfault at least once in 24 hour period.
> Traffic volume is low around 6 MB/s across all 10 servers. The idea was to
> put more traffic onto but I need to resolve this first.
> Okay I stipped the binaries so the core dump information isn't as help as it
> could be but it indicates the issue happened inside
> insert_via_header_in_request.
> (gdb) bt
> #0 0x00000000006f2ef3 in ink_stack_trace_dump ()
> #1 0x0000000000502f8a in ?? ()
> #2 <signal handler called>
> #3 0x0000000000580903 in HttpTransactHeaders::insert_via_header_in_request ()
> #4 0x0000000000562a3a in HttpTransact::build_request ()
> #5 0x00000000005790f6 in HttpTransact::HandleCacheOpenReadHit ()
> #6 0x0000000000534485 in HttpSM::call_transact_and_set_next_state ()
> #7 0x000000000054b35b in HttpSM::set_next_state ()
> #8 0x0000000000534469 in HttpSM::call_transact_and_set_next_state ()
> #9 0x0000000000536a62 in HttpSM::do_hostdb_lookup ()
> #10 0x000000000054b5db in HttpSM::set_next_state ()
> #11 0x0000000000534469 in HttpSM::call_transact_and_set_next_state ()
> #12 0x000000000054b35b in HttpSM::set_next_state ()
> #13 0x0000000000534469 in HttpSM::call_transact_and_set_next_state ()
> #14 0x000000000054b35b in HttpSM::set_next_state ()
> #15 0x0000000000534469 in HttpSM::call_transact_and_set_next_state ()
> #16 0x0000000000549491 in HttpSM::state_cache_open_read ()
> #17 0x0000000000547e3b in HttpSM::main_handler ()
> #18 0x000000000052457e in HttpCacheSM::state_cache_open_read ()
> #19 0x0000000000694dc4 in CacheVC::openReadStartEarliest ()
> #20 0x000000000066e3c0 in CacheVC::handleReadDone ()
> #21 0x00000000006756fb in AIOCallbackInternal::io_complete ()
> #22 0x00000000006e3614 in EThread::process_event ()
> #23 0x00000000006e3f5b in EThread::execute ()
> #24 0x00000000006e1a72 in ?? ()
> #25 0x00002b9c8dd73fc7 in start_thread () from /lib/libpthread.so.0
> #26 0x00002b9c8f4e564d in clone () from /lib/libc.so.6
> #27 0x0000000000000000 in ?? ()
> The segfault issue was the same for all concerned servers.
> I'll see if I can put the unstripped binaries back on so we can get more
> information.
> Ricky
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
