[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258469#comment-14258469
]
Sudheer Vinukonda edited comment on TS-3083 at 12/24/14 7:23 PM:
-----------------------------------------------------------------
[~tufang14] : FetchSM::cleanUp() may be called twice (from two different
threads even) via {{SpdyRequest::clear()}} and {{FetchSM::InvokePluginExt()}}.
We don't enable reclaimable free lists in our production, but, we did see some
cores a few months ago, around this area due to double delete.
You may try the below patch (that we tested briefly, although, we never rolled
to production, since we stopped seeing these cores sometime back) to see if it
resolves the issue you are noticing.
{code}
diff --git a/proxy/FetchSM.cc b/proxy/FetchSM.cc
index c5fc04b..34f3dfc 100644
--- a/proxy/FetchSM.cc
+++ b/proxy/FetchSM.cc
@@ -30,12 +30,23 @@
#define DEBUG_TAG "FetchSM"
#define FETCH_LOCK_RETRY_TIME HRTIME_MSECONDS(10)
+static ink_mutex ink_mutex_fetch_sm_initializer = INK_MUTEX_INIT;
+
ClassAllocator < FetchSM > FetchSMAllocator("FetchSMAllocator");
void
FetchSM::cleanUp()
{
Debug(DEBUG_TAG, "[%s] calling cleanup", __FUNCTION__);
+ ink_scoped_mutex fetch_sm_mutex(ink_mutex_fetch_sm_initializer);
+ if (!destroyed) {
+ destroyed = true;
+ } else {
+ Debug(DEBUG_TAG, "Error: Double delete: FetchSM has already been
destroyed. this:%p", this);
+ return;
+ }
+
+
if (resp_is_chunked > 0 && (fetch_flags & TS_FETCH_FLAGS_DECHUNK)) {
chunked_handler.clear();
}
diff --git a/proxy/FetchSM.h b/proxy/FetchSM.h
index c48bb4f..076e092 100644
--- a/proxy/FetchSM.h
+++ b/proxy/FetchSM.h
@@ -52,6 +52,7 @@ public:
header_done = 0;
user_data = NULL;
has_sent_header = false;
+ destroyed = false;
req_content_length = 0;
resp_is_chunked = -1;
resp_content_length = -1;
@@ -167,6 +168,7 @@ private:
bool header_done;
bool is_method_head;
bool is_internal_request;
+ bool destroyed;
IpEndpoint _addr;
int resp_is_chunked;
int resp_received_close;
{code}
was (Author: sudheerv):
[~tufang14] : FetchSM::cleanUp() may be called twice (from two different
threads even) via {{SpdyRequest::clear()}} and {{FetchSM::InvokePluginExt()}}.
We don't enable reclaimable free lists in our production, but, we did see some
cores a few months ago, around this area due to double delete.
You may try the below patch (that we tested briefly, although, we never rolled
to production, since we stopped seeing these cores sometime back) addresses the
issue you are noticing.
{code}
diff --git a/proxy/FetchSM.cc b/proxy/FetchSM.cc
index c5fc04b..34f3dfc 100644
--- a/proxy/FetchSM.cc
+++ b/proxy/FetchSM.cc
@@ -30,12 +30,23 @@
#define DEBUG_TAG "FetchSM"
#define FETCH_LOCK_RETRY_TIME HRTIME_MSECONDS(10)
+static ink_mutex ink_mutex_fetch_sm_initializer = INK_MUTEX_INIT;
+
ClassAllocator < FetchSM > FetchSMAllocator("FetchSMAllocator");
void
FetchSM::cleanUp()
{
Debug(DEBUG_TAG, "[%s] calling cleanup", __FUNCTION__);
+ ink_scoped_mutex fetch_sm_mutex(ink_mutex_fetch_sm_initializer);
+ if (!destroyed) {
+ destroyed = true;
+ } else {
+ Debug(DEBUG_TAG, "Error: Double delete: FetchSM has already been
destroyed. this:%p", this);
+ return;
+ }
+
+
if (resp_is_chunked > 0 && (fetch_flags & TS_FETCH_FLAGS_DECHUNK)) {
chunked_handler.clear();
}
diff --git a/proxy/FetchSM.h b/proxy/FetchSM.h
index c48bb4f..076e092 100644
--- a/proxy/FetchSM.h
+++ b/proxy/FetchSM.h
@@ -52,6 +52,7 @@ public:
header_done = 0;
user_data = NULL;
has_sent_header = false;
+ destroyed = false;
req_content_length = 0;
resp_is_chunked = -1;
resp_content_length = -1;
@@ -167,6 +168,7 @@ private:
bool header_done;
bool is_method_head;
bool is_internal_request;
+ bool destroyed;
IpEndpoint _addr;
int resp_is_chunked;
int resp_received_close;
{code}
> crash
> -----
>
> Key: TS-3083
> URL: https://issues.apache.org/jira/browse/TS-3083
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.0
> Reporter: bettydramit
> Assignee: Zhao Yongming
> Labels: crash
> Fix For: sometime
>
>
> c++filt <a.txt
> {code}
> /lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
> /usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
> /usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
> /usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
> /usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
> /usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
> /usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
> /usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
> /usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
> /usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
> /usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
> /usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
