[
https://issues.apache.org/jira/browse/AMQCPP-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557239#comment-13557239
]
Jeffrey B commented on AMQCPP-449:
----------------------------------
I think I have some insight here, it seems as though in the file
decaf/interal/util/concurrent/Threading.cpp:838 Atomics::shutdown() is called,
this destroys a mutex (possibly address 0x2000000040089480).
Then just below in the loop iterating throught the vector, when it calls delete
on a thread, possibly the first one,
The destructor calls Trheading::destroyThread(this->properties->handle)
It is not an osThread, so PlatformThread::detachOSThread(thread->handle) is
called, but does no action.
Then dereferenceThread(thread) is called and it does
Atomics::decremenetAndGet(&(thread->references))
This fucntion attempts to lock atomicMutex with
PlatformThread::lockMutex(atomicMutex) which is still 0x2000000040089480, but
has already been destroyed.
That is when pthread_mutex_lock(mutex) fails and return 22 because the adderss
no longer contains a valid mutex.
It looks to me that at least when you do not have atomic builtins and when you
are not on Solaris, then the threading implementation depends on the Atomics
class.
Let me know if this sound plausible or am I way off. Im using the debugger, but
when attempting to debug with threads, it works a little bit oddly.
> activemq::library::ActiveMQCPP::shutdownLibrary(); causing runtime exception
> ----------------------------------------------------------------------------
>
> Key: AMQCPP-449
> URL: https://issues.apache.org/jira/browse/AMQCPP-449
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Decaf
> Affects Versions: 3.5.0
> Environment: HPUX 11.31
> Reporter: Jeffrey B
> Assignee: Timothy Bish
> Priority: Critical
> Labels: HPUX, crash, destructor, exception, runtime, thread
> Attachments: amqdriver.cpp, amqdriver.cpp
>
>
> Whenever my simple driver application or my receiver application call the
> shutdownLibrary() method at the end, as the program is going through
> desctuctors for threads it prints and causes a core dump
> aCC runtime: Unexpected exception of type
> "decaf::lang::exceptions::RuntimeException".
> aCC runtime: what(): Failed to Lock OS Mutex
> Abort(coredump)
> I added another catch and print in decaf/lang/Thread.cpp about line 133 and
> on decaf/internal/util/concurrent/unix/PlatformThread.cpp about line 76 i
> printed out ther error number return from pthread_mutex_lock()
> Now i get:
> Failed to Lock OS Mutex, Error num: 22
> FILE: decaf/internal/util/concurrent/unix/PlatformThread.cpp, LINE: 78
> aCC runtime: Unexpected exception of type
> "decaf::lang::exceptions::RuntimeException".
> aCC runtime: what(): Failed to Lock OS Mutex, Error num: 22
> Abort(coredump)
> Error 22 is EINVAL and can have two meanings on my system:
> mutex is a PTHREAD_PRIO_PROTECT mutex and the caller's priority is
> higher than mutex's priority ceiling.
> mutex is not an initialized mutex.
> I'll try and upload my code to see if this happens on other systems as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
