You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2014/05/01 06:10:16 UTC
[jira] [Commented] (TS-2757) logging crashes on reconfiguration
[ https://issues.apache.org/jira/browse/TS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986329#comment-13986329 ]
ASF subversion and git services commented on TS-2757:
-----------------------------------------------------
Commit 929296988bbb13561af8420153666e190cd2a259 in trafficserver's branch refs/heads/master from [~jpeach@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9292969 ]
TS-2757: logging crashes on reconfiguration
The way that LogObjectManager transfers LogObjects to the new manager
when logging is reconfigured is prone to crashes since the previous
object manager can be used after the objects have been transferred
out of it. The solution to this is to persist the objects in the
manager for the whole of the manager's lifetime. This require adding
reference counting so that multiple managers can safely share
ownership of the same objects.
Added a TSQA test to exercise this code path. Plugged a LogFormat
leak when creating new TextLogObjects.
> logging crashes on reconfiguration
> ----------------------------------
>
> Key: TS-2757
> URL: https://issues.apache.org/jira/browse/TS-2757
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 5.0.0
> Reporter: James Peach
> Assignee: James Peach
> Labels: A
> Fix For: 5.0.0
>
>
> If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects are deleted, the object manager crashes. It looks like {{_APIobjects}} has a stale pointer.
> {code}
> (gdb) bt
> #0 0x00000000005e8c47 in LogObjectManager::~LogObjectManager (this=0x4bf0028, __in_chrg=<value optimized out>) at LogObject.cc:903
> #1 0x00000000005d33e2 in LogConfig::~LogConfig (this=0x4bf0000, __in_chrg=<value optimized out>) at LogConfig.cc:573
> #2 0x00000000005d3446 in LogConfig::~LogConfig (this=0x4bf0000, __in_chrg=<value optimized out>) at LogConfig.cc:573
> #3 0x0000000000617b8a in ConfigProcessor::release (this=0xafa720, id=5, info=0x4bf0000) at ProxyConfig.cc:210
> #4 0x0000000000618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00) at ProxyConfig.cc:106
> #5 0x00000000004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2, data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
> #6 0x00000000006d17b6 in EThread::process_event (this=0x2e08000, e=0xe926780, calling_code=2) at UnixEThread.cc:145
> #7 0x00000000006d1ad1 in EThread::execute (this=0x2e08000) at UnixEThread.cc:224
> #8 0x00000000006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
> #9 0x00002b507e273851 in start_thread () from /lib64/libpthread.so.0
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)