You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (JIRA)" <ji...@apache.org> on 2013/01/16 09:06:13 UTC
[jira] [Commented] (TS-1653) Crash report:
HostDBContinuation::probeEvent MutexTryLock
[ https://issues.apache.org/jira/browse/TS-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554827#comment-13554827 ]
Alan M. Carroll commented on TS-1653:
-------------------------------------
You might look at HostDB.cc : put_hostinfo_ClusterFunction() which sets the continuation mutex but not the action.mutex. You could probably set action.mutex = c->mutex there - see other examples in the file of doing that.
> Crash report: HostDBContinuation::probeEvent MutexTryLock
> ---------------------------------------------------------
>
> Key: TS-1653
> URL: https://issues.apache.org/jira/browse/TS-1653
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Zhao Yongming
> Assignee: Alan M. Carroll
>
> {code}
> Core was generated by `/usr/bin/traffic_server -M --httpport 8080:fd=7'.
> Program terminated with signal 11, Segmentation fault.
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at ../iocore/eventsystem/I_Lock.h:170
> 170 if (m->thread_holding != t) {
> Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.47.el6_2.9.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 openssl-1.0.0-20.el6_2.4.x86_64 pcre-7.8-3.1.el6.x86_64 tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at ../iocore/eventsystem/I_Lock.h:170
> #1 MutexTryLock::MutexTryLock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at ../iocore/eventsystem/I_Lock.h:385
> #2 0x00000000005b38dc in HostDBContinuation::probeEvent (this=0x2b997329df10, event=<value optimized out>, e=0x2b99b8050030) at HostDB.cc:1762
> #3 0x000000000065a1b4 in handleEvent (this=0x2b9948fea010, e=0x2b99b8050030, calling_code=2) at I_Continuation.h:146
> #4 EThread::process_event (this=0x2b9948fea010, e=0x2b99b8050030, calling_code=2) at UnixEThread.cc:142
> #5 0x000000000065ad83 in EThread::execute (this=0x2b9948fea010) at UnixEThread.cc:221
> #6 0x00000000006594d2 in spawn_thread_internal (a=0x2fb8350) at Thread.cc:88
> #7 0x0000003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #8 0x0000003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 2
> #2 0x00000000005b38dc in HostDBContinuation::probeEvent (this=0x2b997329df10, event=<value optimized out>, e=0x2b99b8050030) at HostDB.cc:1762
> 1762 MUTEX_TRY_LOCK_FOR(lock, action.mutex, t, action.continuation);
> (gdb) p action.mutex
> $1 = {m_ptr = 0x0}
> (gdb) p t
> $2 = <value optimized out>
> (gdb) p action
> $3 = {_vptr.Action = 0x6601d0, continuation = 0x0, mutex = {m_ptr = 0x0}, cancelled = 1}
> (gdb)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira