You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Thomas Pohl (Jira)" <ji...@apache.org> on 2021/01/13 14:49:00 UTC
[jira] [Comment Edited] (AMQCPP-625) Inactivity mointor core dump
[ https://issues.apache.org/jira/browse/AMQCPP-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17264195#comment-17264195 ]
Thomas Pohl edited comment on AMQCPP-625 at 1/13/21, 2:48 PM:
--------------------------------------------------------------
I can confirm the issue and saw it a number of times. The reason for exactly this stack trace is that the InactivityMonitor doesn't destroy it's timers first. So during destruction threads still access the half destroyed monitor object. It's really hard to prove in a reliable fashion. But I've been able to fix this by simply ensure the two timer variables are the last once declared. This ensures that they are destroyed before the other data structures.
was (Author: mail@thomas-pohl.de):
I can confirm the issue and saw it a number of times. Somehow the reason for that the InactivityMonitor doesn't destroy it's timers first. So during destruction threads still access the monitor and this causes the threads. It's really hard to prove in a reliable fashion. But I've been able to fix this by simply ensure the Timer variables are the last once declared.
> Inactivity mointor core dump
> -----------------------------
>
> Key: AMQCPP-625
> URL: https://issues.apache.org/jira/browse/AMQCPP-625
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Decaf, Openwire
> Reporter: Satadip Dutta
> Assignee: Timothy A. Bish
> Priority: Critical
> Attachments: timerCrash.patch
>
>
> Broker Configuration:
> ----------------------------
> <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600&transport.useInactivityMonitor=false"/>
> Client configuration:
> ---------------------------
> failover://(tcp://192.168.114.105:61616,tcp://192.168.114.105:61616)?randomize=false&wireFormat=openwire&transport.useInactivityMonitor=false
>
> Application cores/crashes/segfaults and generates core file, even when in idle state. Below is the backtrace - Not sure if this is related to inactivity monitor
> (gdb) bt
> #0 0x00007f2dd9bff989 in raise () from /lib64/libc.so.6
> #1 0x00007f2dd9c01098 in abort () from /lib64/libc.so.6
> #2 0x00007f2dda5039d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
> #3 0x00007f2dda501946 in ?? () from /lib64/libstdc++.so.6
> #4 0x00007f2dda501973 in std::terminate() () from /lib64/libstdc++.so.6
> #5 0x00007f2dda5024df in __cxa_pure_virtual () from /lib64/libstdc++.so.6
> #6 0x00007f2ddc404baa in decaf::util::concurrent::Lock::~Lock (this=0x7f2d637fdbf0, __in_chrg=<optimized out>) at decaf/util/concurrent/Lock.cpp:46
> #7 0x00007f2ddc221e80 in activemq::threads::CompositeTaskRunner::wakeup (this=<optimized out>) at activemq/threads/CompositeTaskRunner.cpp:154
> #8 0x00007f2ddc282c95 in activemq::transport::inactivity::InactivityMonitor::readCheck (this=0x7f2d70003a50)
> at activemq/transport/inactivity/InactivityMonitor.cpp:400
> #9 0x00007f2ddc3ffe5d in decaf::util::TimerImpl::run (this=0x7f2d70002160) at decaf/util/Timer.cpp:156
> #10 0x00007f2ddc37b622 in (anonymous namespace)::runCallback (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:268
> #11 0x00007f2ddc37beec in (anonymous namespace)::threadEntryMethod (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:256
> #12 0x00007f2dda9b4df3 in start_thread () from /lib64/libpthread.so.0
> #13 0x00007f2dd9cc03dd in clone () from /lib64/libc.so.6
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)