[
https://issues.apache.org/jira/browse/TS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812092#comment-13812092
]
Alan M. Carroll commented on TS-2264:
-------------------------------------
On my test box it crashes almost every time.
I've tracked it down to the reentrancy_count not be set correctly. This happens
if transaction never blocks and gets all the way to setting terminate_sm on the
call HttpSM::attachClientSession(). If that gets blocked at any point then the
rescheduling will go through HttpSM::mainHandler which will set
reentrancy_count correctly and you won't get the crash. I presume this is what
is happening in your case, Mohammad.
The point of reentrancy_count is to prevent the SM from getting cleaned up (via
HttpSM::kill_this()) before the call stack has unwound. Unfortunately in the
particular case I am observing this is not true and HttpSM::mainHandler does
the clean up while there is still a long call chain to unwind. In this case
it's about 25 calls deep from HttpSM::attachClientSession *after*
HttpSM::kill_this() is called and not rooted in mainHandler or
state_api_callout. It varies a bit but somewhere along that call chain unwind
the fact that the SM has been destroyed causes a crash.
> The current cache connection counter is not reliably decremented with
> use_client_source_port
> --------------------------------------------------------------------------------------------
>
> Key: TS-2264
> URL: https://issues.apache.org/jira/browse/TS-2264
> Project: Traffic Server
> Issue Type: Bug
> Components: TProxy
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Priority: Minor
> Fix For: 4.2.0
>
>
> If use_client_target_addr and use_client_source_port are enabled with
> transparent proxy, in some cases the current cache connection counter is not
> decremented. This happens when a client connection is terminated due to an
> EADDRNOTAVAIL failure.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
