[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-3156:
-------------------------------
Backport to Version: 5.2.0
This causes very frequent crashes, in the TLS session manager.
{code}
#0 Mutex_lock (t=0x3060000, m=0x0) at ../../iocore/eventsystem/I_Lock.h:391
#1 acquire (t=0x3060000, this=0x2b4c654c64c0) at
../../iocore/eventsystem/I_Lock.h:517
#2 SSLSessionBucket::getSession (this=this@entry=0x28b9c08, id=...,
sess=sess@entry=0x2b4c654c65b0) at SSLSessionCache.cc:160
#3 0x00000000007463bf in SSLSessionCache::getSession (this=<optimized out>,
sid=..., sess=sess@entry=0x2b4c654c65b0)
at SSLSessionCache.cc:63
#4 0x00000000007242f9 in ssl_get_cached_session (ssl=0x21324200, id=<optimized
out>, len=<optimized out>, copy=<optimized out>)
at SSLUtils.cc:194
#5 0x00002b4c5edcc602 in ssl_get_prev_session (s=s@entry=0x21324200,
session_id=0x213c8027
"\340\250\\\347\363N\020\024\066(\257#>\027\234\206\345\316.\313\347?\257GM\310@\356\316\002\031-",
len=len@entry=32, limit=limit@entry=0x213c80a2 "") at ssl_sess.c:528
#6 0x00002b4c5eda2953 in ssl3_get_client_hello (s=s@entry=0x21324200) at
s3_srvr.c:1017
#7 0x00002b4c5eda73dd in ssl3_accept (s=0x21324200) at s3_srvr.c:357
#8 0x00002b4c5edb4e58 in ssl23_accept (s=0x21324200) at s23_srvr.c:210
#9 0x0000000000729499 in SSLAccept (ssl=0x21324200) at SSLUtils.cc:1829
#10 0x000000000071ecbd in SSLNetVConnection::sslServerHandShakeEvent
(this=this@entry=0x4350f50, err=@0x2b4c654c6c40: 70681056)
at SSLNetVConnection.cc:954
#11 0x000000000071f641 in SSLNetVConnection::sslStartHandShake (this=0x4350f50,
event=<optimized out>, err=@0x2b4c654c6c40: 70681056)
at SSLNetVConnection.cc:873
#12 0x000000000072110e in SSLNetVConnection::net_read_io (this=0x4350f50,
nh=0x3063ac0, lthread=0x3060000) at SSLNetVConnection.cc:433
#13 0x000000000072b8e2 in NetHandler::mainNetEvent (this=0x3063ac0,
event=<optimized out>, e=<optimized out>) at UnixNet.cc:399
#14 0x000000000075aa0a in handleEvent (data=0x22752e0, event=5, this=<optimized
out>) at I_Continuation.h:146
#15 process_event (calling_code=5, e=0x22752e0, this=0x3060000) at
UnixEThread.cc:144
#16 EThread::execute (this=0x3060000) at UnixEThread.cc:268
#17 0x000000000075947a in spawn_thread_internal (a=0x1c3e870) at Thread.cc:88
#18 0x00002b4c6087eee5 in start_thread (arg=0x2b4c654c7700) at
pthread_create.c:309
#19 0x00002b4c6191ab8d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) frame 1
#1 acquire (t=0x3060000, this=0x2b4c654c64c0) at
../../iocore/eventsystem/I_Lock.h:517
517 MUTEX_TAKE_LOCK(m.m_ptr, t);
(gdb) print m
$10 = {m_ptr = 0x0}
{code}
> Mutex[Try]Lock bool() operator change and unused API removal
> ------------------------------------------------------------
>
> Key: TS-3156
> URL: https://issues.apache.org/jira/browse/TS-3156
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Powell Molleti
> Assignee: James Peach
> Priority: Minor
> Labels: review
> Fix For: 5.2.0
>
> Attachments: MutexLock-ats.patch, MutexLock-ats.patch,
> Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch
>
>
> Removed unused constructor in MutexLock along with set_and_take() method, had
> to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
> default bool and ! operator from both MutexLock and MutexTryLock with
> is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
> base.
> Ran make test will be performing more system testing. Posted before for early
> comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
