You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2011/04/01 17:05:07 UTC
[jira] [Commented] (TS-729) Seg faults within
HttpTransactHeaders::insert_via_header_in_request
[ https://issues.apache.org/jira/browse/TS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014654#comment-13014654 ]
Leif Hedstrom commented on TS-729:
----------------------------------
I assume there's no chance you will be able to test v2.1.7 ? Also, do you know which line it's crashing on ? And what the values on parameters and local variables are?
> 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