activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-626) ActiveMQ C++ client crashes with `_purecall`
Date Mon, 12 Mar 2018 15:28:02 GMT

    [ https://issues.apache.org/jira/browse/AMQCPP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395398#comment-16395398
] 

ASF GitHub Bot commented on AMQCPP-626:
---------------------------------------

GitHub user unjello opened a pull request:

    https://github.com/apache/activemq-cpp/pull/5

    Move timer objects to the end of member list

    In high CPU load it can happen, that Timer thread wakes up,
    is swapped out, and when application resumes it does not resume with timer
    thread, but transport thread, that decides to do failover, destroys
    `InactivityMonitor` object. When its members are getting destroyed,
    they arrive at `Timer` object that joins, timer thread resumes in
    `writeCheck` or `readCheck` method, only to find out `asyncTasks` is already
    destroyed because it comes later in member declaration list so it was
    destroyed first. Moving `Timer` object to the end of the list, guarantees
    that they will be destroyed first, so their threads will get joined and
    allowed to finish, before the rest of the object is destroyed.
    
    Closes AMQCPP-626

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/unjello/activemq-cpp fix/amqcpp-626

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-cpp/pull/5.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #5
    
----
commit fced83a9da3531e0b6875c80714d47424449f29c
Author: Andrzej Lichnerowicz <andrzej@...>
Date:   2018-03-12T15:20:31Z

    Move timer objects to the end of member list
    
    In high CPU load it can happen, that Timer thread wakes up,
    is swapped out, and when application resumes it does not resume with timer
    thread, but transport thread, that decides to do failover, destroys
    `InactivityMonitor` object. When its members are getting destroyed,
    they arrive at `Timer` object that joins, timer thread resumes in
    `writeCheck` or `readCheck` method, only to find out `asyncTasks` is already
    destroyed because it comes later in member declaration list so it was
    destroyed first. Moving `Timer` object to the end of the list, guarantees
    that they will be destroyed first, so their threads will get joined and
    allowed to finish, before the rest of the object is destroyed.
    
    Closes AMQCPP-626

----


> ActiveMQ C++ client crashes with `_purecall`
> --------------------------------------------
>
>                 Key: AMQCPP-626
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-626
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Decaf, Transports
>    Affects Versions: 3.1, 3.1.1, 3.1.2, 3.1.3, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5,
3.3.0, 3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.5.0, 3.6.0, 3.7.0, 3.7.1, 3.8.0, 3.8.1,
3.8.2, 3.8.3, 3.8.4, 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>            Reporter: Andrzej Lichnerowicz
>            Assignee: Timothy Bish
>            Priority: Major
>
> Inactivty monitor, during failover, in high CPU load conditions can crash an application.
>  
> {{0:031> k}}
> {{  *** Stack trace for last set context - .thread/.cxr resets it}}
> {{ # ChildEBP RetAddr  }}
> {{00 1323f880 614b4f3b ucrtbase!abort+0x4b}}
> {{01 1323f888 5a16e846 VCRUNTIME140!_purecall+0x1b [f:\dd\vctools\crt\vcruntime\src\misc\purevirt.cpp
@ 29] }}
> {{WARNING: Stack unwind information not available. Following frames may be wrong.}}
> {{02 1323f8c8 5a0383d4 activemq_cpp!decaf::util::concurrent::Lock::~Lock+0x46}}
> {{03 1323f8f0 5a067077 activemq_cpp!activemq::threads::CompositeTaskRunner::wakeup+0x74}}
> {{04 1323f924 5a068188 activemq_cpp!activemq::transport::inactivity::InactivityMonitor::writeCheck+0x47}}
> {{05 1323f938 5a15cd24 activemq_cpp!activemq::transport::inactivity::WriteChecker::run+0x48}}
> {{06 1323fa20 5a0f25ac activemq_cpp!decaf::util::StringTokenizer::reset+0xa04}}
> {{07 1323fa74 5a0f254b activemq_cpp!decaf::internal::util::concurrent::SynchronizableImpl::~SynchronizableImpl+0x4cc}}
> {{08 1323faac 60c78824 activemq_cpp!decaf::internal::util::concurrent::SynchronizableImpl::~SynchronizableImpl+0x46b}}
> {{09 1323fae8 76a27c04 ucrtbase!_crt_atexit+0x104}}
> {{0a 1323fafc 777fad2f kernel32!BaseThreadInitThunk+0x24}}
> {{0b 1323fb44 777facfa ntdll!__RtlUserThreadStart+0x2f}}
> {{0c 1323fb54 00000000 ntdll!_RtlUserThreadStart+0x1b}}
>  
> It seems to be introduced by a commit 69739ab64c4cd140a5d92f15a64725d3386f86ce from Nov
2009, so looks like since very introduction of Inactivity Monitor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message