You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "B Wyatt (Commented) (JIRA)" <ji...@apache.org> on 2011/10/10 17:53:29 UTC

[jira] [Commented] (TS-934) Proxy Mutex null pointer crash

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

B Wyatt commented on TS-934:
----------------------------

>From the cores/callstacks I've seen this is the same issue as TS-857.
                
> Proxy Mutex null pointer crash
> ------------------------------
>
>                 Key: TS-934
>                 URL: https://issues.apache.org/jira/browse/TS-934
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>         Environment: Debian 6.0.2 quadcore, forward transparent proxy.
>            Reporter: Alan M. Carroll
>            Assignee: Alan M. Carroll
>             Fix For: 3.1.1
>
>         Attachments: ts-934-patch.txt
>
>
> [Client report]
> We had the cache crash gracefully twice last night on a segfault.  Both 
> times the callstack produced by trafficserver's signal handler was:
> /usr/bin/traffic_server[0x529596]
> /lib/libpthread.so.0(+0xef60)[0x2ab09a897f60]
> [0x2ab09e7c0a10]
> usr/bin/traffic_server(HttpServerSession::do_io_close(int)+0xa8)[0x567a3c]
> /usr/bin/traffic_server(HttpVCTable::cleanup_entry(HttpVCTableEntry*)+0x4c)[0x56aff6]
> /usr/bin/traffic_server(HttpVCTable::cleanup_all()+0x64)[0x56b07a]
> /usr/bin/traffic_server(HttpSM::kill_this()+0x120)[0x57c226]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x208)[0x571b28]
> /usr/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x69)[0x4e4623]
> I went through the disassembly and the instruction that it is on in 
> ::do_io_close is loading the value of diags (not dereferencing it) so it 
> is unlikely that that through a segfault (unless this is some how in 
> thread local storage and that is corrupt).
> The kernel message claimed that the instruction pointer was 0x4e438e 
> which in this build is in ProxyMutexPtr::operator ->() on the 
> instruction that dereferences the object pointer to get the stored mutex 
> pointer (bingo!), so it would seem that at some point we are 
> dereferencing a null "safe" pointer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira