GitHub user shinrich opened an issue:

    https://github.com/apache/trafficserver/issues/1476

    Crash in get_client_addr()

    After working through issues #1401 and #1443, we now see the following 
crash in our copy of 7.1.  The crash occurs once every couple hours.
    
    ```
    #0  0x00002b46debb3867 in ?? () from /lib64/libgcc_s.so.1
    #1  0x00002b46debb4119 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
    #2  0x00002b46deeb9936 in backtrace () from /lib64/libc.so.6
    #3  0x00002b46dc70fe72 in ink_stack_trace_dump () at ink_stack_trace.cc:61
    #4  0x00002b46dc71213a in signal_crash_handler (signo=11) at signals.cc:186
    #5  0x0000000000513414 in crash_logger_invoke (signo=11, 
info=0x2b46e39dc130, ctx=0x2b46e39dc000) at Crash.cc:169
    #6  <signal handler called>
    #7  0x0000000000000001 in ?? () at ../../lib/ts/Diags.h:142
    #8  0x00000000005126d5 in NetVConnection::get_remote_addr 
(this=0x2aad1cc4d0a0)
        at 
/home/shinrich/yats_build/trafficserver/iocore/net/P_NetVConnection.h:30
    #9  0x000000000055deea in ProxyClientSession::get_client_addr 
(this=0x2ab0dc25bba0) at ProxyClientSession.h:221
    #10 0x00000000005352bf in TSHttpSsnClientAddrGet (ssnp=0x2ab0dc25bba0) at 
InkAPI.cc:5439
    #11 0x000000000053530d in TSHttpTxnClientAddrGet (txnp=0x2b474440c9f0) at 
InkAPI.cc:5447
    #12 0x00002aaaae4008f6 in http_hook (contp=0x1e42f40, event=60006, 
edata=0x2b474440c9f0) at INKPluginInit.cc:174
    #13 0x000000000052a5fd in INKContInternal::handle_event (this=0x1e42f40, 
event=60006, edata=0x2b474440c9f0) at InkAPI.cc:1048
    #14 0x00000000005160f2 in Continuation::handleEvent (this=0x1e42f40, 
event=60006, data=0x2b474440c9f0)
        at 
/home/shinrich/yats_build/trafficserver/iocore/eventsystem/I_Continuation.h:153
    #15 0x000000000052adf3 in APIHook::invoke (this=0x1e44f40, event=60006, 
edata=0x2b474440c9f0) at InkAPI.cc:1267
    #16 0x00000000005e5e16 in HttpSM::state_api_callout (this=0x2b474440c9f0, 
event=0, data=0x0) at HttpSM.cc:1462
    #17 0x00000000005f3a11 in HttpSM::do_api_callout_internal 
(this=0x2b474440c9f0) at HttpSM.cc:5171
    #18 0x0000000000601b85 in HttpSM::do_api_callout (this=0x2b474440c9f0) at 
HttpSM.cc:438
    #19 0x00000000005e78d6 in HttpSM::state_read_server_response_header 
(this=0x2b474440c9f0, event=100, data=0x2b4744cac508)
        at HttpSM.cc:1962
    #20 0x00000000005ea331 in HttpSM::main_handler (this=0x2b474440c9f0, 
event=100, data=0x2b4744cac508) at HttpSM.cc:2662
    #21 0x00000000005160f2 in Continuation::handleEvent (this=0x2b474440c9f0, 
event=100, data=0x2b4744cac508)
        at 
/home/shinrich/yats_build/trafficserver/iocore/eventsystem/I_Continuation.h:153
    #22 0x000000000078489f in read_signal_and_update (event=100, 
vc=0x2b4744cac3e0) at UnixNetVConnection.cc:145
    #23 0x0000000000787a10 in UnixNetVConnection::readSignalAndUpdate 
(this=0x2b4744cac3e0, event=100) at UnixNetVConnection.cc:1125
    #24 0x000000000076a098 in SSLNetVConnection::net_read_io 
(this=0x2b4744cac3e0, nh=0x2b46e18ade60, lthread=0x2b46e18aa010)
        at SSLNetVConnection.cc:587
    #25 0x000000000077d20d in NetHandler::mainNetEvent (this=0x2b46e18ade60, 
event=5, e=0x1873f20) at UnixNet.cc:509
    #26 0x00000000005160f2 in Continuation::handleEvent (this=0x2b46e18ade60, 
event=5, data=0x1873f20)
        at 
/home/shinrich/yats_build/trafficserver/iocore/eventsystem/I_Continuation.h:153
    #27 0x00000000007a69c5 in EThread::process_event (this=0x2b46e18aa010, 
e=0x1873f20, calling_code=5) at UnixEThread.cc:143
    #28 0x00000000007a6eb1 in EThread::execute (this=0x2b46e18aa010) at 
UnixEThread.cc:270
    #29 0x00000000007a6089 in spawn_thread_internal (a=0x1762fe0) at 
Thread.cc:84
    #30 0x00002b46df156aa1 in start_thread () from /lib64/libpthread.so.0
    #31 0x00002b46deea393d in clone () from /lib64/libc.so.6
    ```
    I assume that there has been a goodly amount of inlining here so it is hard 
to tell how we got from NetVConnection::get_remote_addr to the Diags::on 
method.  Digging through the core, the cached member addresses seem ok, and I 
don't see evidence of thread races.
    
    I think I have seen this stack reported before, but couldn't find the issue.

----

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to