[
https://issues.apache.org/activemq/browse/AMQCPP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50611#action_50611
]
Alexander Martens commented on AMQCPP-205:
------------------------------------------
Hi!
Dario, this issue is related to a specific integration test. As Timothy pointed
out, it looks more like your server stopped responding. Check your activemq.log
for exceptions or use "top" to see if your server is running out of memory. (If
you find a way to reproduce it don't hesitate to open a new issue.)
There is a 2.2.4 release for activemq-cpp and a 5.2 for ActiveMQ. Trying an
update is, IMHO, always the worth it.
Timothy, indeed, this curious deadlock may still happen (new build with 2.2.4)
- don't know if this is actually interesting.
On loop #12 (CentOS)
{noformat}
Thread 3 (Thread 1096817552 (LWP 14095)):
#0 0x40000402 in __kernel_vsyscall ()
#1 0x00853256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x4059ac1f in apr_thread_cond_wait (cond=0x9689248, mutex=0x967b210) at
locks/unix/thread_cond.c:68
#3 0x40341229 in decaf::util::concurrent::Mutex::wait (this=0x96664a0,
millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:118
#4 0x40340ee6 in decaf::util::concurrent::Mutex::wait (this=0x96664a0) at
decaf/util/concurrent/Mutex.cpp:82
#5 0x40249f3c in activemq::core::ActiveMQSessionExecutor::run (this=0x9666488)
at activemq/core/ActiveMQSessionExecutor.cpp:222
#6 0x4032868b in decaf::lang::Thread::runCallback (self=0x95db7b8,
param=0x96666e8) at decaf/lang/Thread.cpp:125
#7 0x405aad48 in dummy_worker (opaque=0x95db7b8) at
threadproc/unix/thread.c:142
#8 0x0084f45b in start_thread () from /lib/libpthread.so.0
#9 0x007a6e5e in clone () from /lib/libc.so.6
Thread 2 (Thread 1098918800 (LWP 14096)):
#0 0x40000402 in __kernel_vsyscall ()
#1 0x00853256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x4059ac1f in apr_thread_cond_wait (cond=0x4114f070, mutex=0x967b210) at
locks/unix/thread_cond.c:68
#3 0x40341229 in decaf::util::concurrent::Mutex::wait (this=0x96664a0,
millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:118
#4 0x40340ee6 in decaf::util::concurrent::Mutex::wait (this=0x96664a0) at
decaf/util/concurrent/Mutex.cpp:82
#5 0x40249f3c in activemq::core::ActiveMQSessionExecutor::run (this=0x9666488)
at activemq/core/ActiveMQSessionExecutor.cpp:222
#6 0x4032868b in decaf::lang::Thread::runCallback (self=0x95db7b8,
param=0x96666e8) at decaf/lang/Thread.cpp:125
#7 0x405aad48 in dummy_worker (opaque=0x95db7b8) at
threadproc/unix/thread.c:142
#8 0x0084f45b in start_thread () from /lib/libpthread.so.0
#9 0x007a6e5e in clone () from /lib/libc.so.6
{noformat}
Best wishes,
Alex
> CmsTemplate testBasics test can hang
> ------------------------------------
>
> Key: AMQCPP-205
> URL: https://issues.apache.org/activemq/browse/AMQCPP-205
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Integration Tests
> Affects Versions: 2.2.1, 2.2.2
> Environment: CentOS / REHL
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Fix For: 3.0
>
> Attachments: cmstemplate.segfault-1.log.gz, receiving.187.log.gz
>
>
> Running the CmsTemplate integration tests in a loop can result in a hang.
> The code appears to be deadlocked when two threads that share the same
> instance of an ActiveMQSessionExecutor are run.
> This snippet from a backtrace shows the case:
> {noformat}
> Thread 3 (Thread 1094732688 (LWP 15620)):
> #0 0x40000402 in __kernel_vsyscall ()
> #1 0x005ac266 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2 0x4056c327 in apr_thread_cond_wait (cond=0x86813a0, mutex=0x40912ae8) at
> locks/unix/thread_cond.c:68
> #3 0x4031e458 in decaf::util::concurrent::Mutex::wait (this=0x409030c0,
> millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:116
> #4 0x4031e13e in decaf::util::concurrent::Mutex::wait (this=0x409030c0) at
> decaf/util/concurrent/Mutex.cpp:82
> #5 0x40238268 in activemq::core::ActiveMQSessionExecutor::run
> (this=0x409030a8) at activemq/core/ActiveMQSessionExecutor.cpp:222
> #6 0x4030589f in decaf::lang::Thread::runCallback (self=0x858f488,
> param=0x40902f08) at decaf/lang/Thread.cpp:121
> #7 0x4057aa1c in dummy_worker (opaque=0x858f488) at
> threadproc/unix/thread.c:142
> #8 0x005a846b in start_thread () from /lib/libpthread.so.0
> #9 0x004ffdbe in clone () from /lib/libc.so.6
> Thread 2 (Thread 1098935184 (LWP 15621)):
> #0 0x40000402 in __kernel_vsyscall ()
> #1 0x005ac266 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2 0x4056c327 in apr_thread_cond_wait (cond=0x86813d8, mutex=0x40912ae8) at
> locks/unix/thread_cond.c:68
> #3 0x4031e458 in decaf::util::concurrent::Mutex::wait (this=0x409030c0,
> millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:116
> #4 0x4031e13e in decaf::util::concurrent::Mutex::wait (this=0x409030c0) at
> decaf/util/concurrent/Mutex.cpp:82
> #5 0x40238268 in activemq::core::ActiveMQSessionExecutor::run
> (this=0x409030a8) at activemq/core/ActiveMQSessionExecutor.cpp:222
> #6 0x4030589f in decaf::lang::Thread::runCallback (self=0x858f488,
> param=0x40902f08) at decaf/lang/Thread.cpp:121
> #7 0x4057aa1c in dummy_worker (opaque=0x858f488) at
> threadproc/unix/thread.c:142
> #8 0x005a846b in start_thread () from /lib/libpthread.so.0
> #9 0x004ffdbe in clone () from /lib/libc.so.6
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
