Lock continuation to avoid handleEvent assert.

[shinrich]

We saw an assert after pulling in the the handleEvent lock/assert fix.

Since I was unclear on the return value expectations, I just added code to grab the action.continuation->mutex lock.

Digging into our core here, the action.mutex and the action.continuation->mutex were different. The action.mutex corresponded to the HostDBContinuation mutex and the action.continuation->mutex corresponded to the HttpSM->mutex.

(gdb) bt
#0  0x00002b08ce8ac1d7 in raise () from /lib64/libc.so.6
#1  0x00002b08ce8ad8c8 in abort () from /lib64/libc.so.6
#2  0x00002b08cbdc9277 in ink_abort (message_format=0x2b08cbdf2080 "%s:%d: failed assertion `%s`")
    at ../../../../trafficserver/lib/ts/ink_error.cc:99
#3  0x00002b08cbdc63c7 in _ink_assert (expression=0x898268 "!mutex || mutex->thread_holding == this_ethread()", 
    file=0x898228 "../../../../trafficserver/iocore/eventsystem/Continuation.cc", line=32)
    at ../../../../trafficserver/lib/ts/ink_assert.cc:37
#4  0x000000000080cfe8 in Continuation::handleEvent (this=0x2b132dc01100, event=500, data=0x1b6f000)
    at ../../../../trafficserver/iocore/eventsystem/Continuation.cc:32
#5  0x000000000072d205 in reply_to_cont (cont=0x2b132dc01100, r=0x1b6f000, is_srv=false)
    at ../../../../trafficserver/iocore/hostdb/HostDB.cc:491
#6  0x0000000000731a43 in HostDBContinuation::dnsEvent (this=0x2b08cbd58010, event=600, e=0x2b09600bb440)
    at ../../../../trafficserver/iocore/hostdb/HostDB.cc:1467
#7  0x000000000080d047 in Continuation::handleEvent (this=0x2b08cbd58010, event=600, data=0x2b09600bb440)
    at ../../../../trafficserver/iocore/eventsystem/Continuation.cc:33
#8  0x000000000074486a in DNSEntry::postEvent (this=0x2b09381c4600) at ../../../../trafficserver/iocore/dns/DNS.cc:1282
#9  0x000000000080d047 in Continuation::handleEvent (this=0x2b09381c4600, event=1, data=0x2b08faf2ec00)
    at ../../../../trafficserver/iocore/eventsystem/Continuation.cc:33
#10 0x000000000080f17d in EThread::process_event (this=0x2b08d5504010, e=0x2b08faf2ec00, calling_code=1)
    at ../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:132
#11 0x000000000080f354 in EThread::process_queue (this=0x2b08d5504010, NegativeQueue=0x2b0924201e10, ev_count=0x2b0924201e08, 
    nq_count=0x2b0924201e0c) at ../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:171
#12 0x000000000080f61c in EThread::execute_regular (this=0x2b08d5504010) at ../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:231
#13 0x000000000080f99b in EThread::execute (this=0x2b08d5504010) at ../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:326
#14 0x000000000080e5d0 in spawn_thread_internal (a=0x19ebf10) at ../../../../trafficserver/iocore/eventsystem/Thread.cc:85
#15 0x00002b08cdc3fdc5 in start_thread () from /lib64/libpthread.so.0
#16 0x00002b08ce96e76d in clone () from /lib64/libc.so.6

[vmamidi]

do we know the when they both are different?

[zwoop]

And what happens when they are the same? Do you not now try to lock the same mutex twice ?

[zwoop]

I'm going to remove the 7.1.5 Project on this, since going forward, we will need to make a second PR against the 7.1.x for proposed back ports.

[bryancall]

Cherry picked to 8.1.0