I finally traced the issue to throwing of an exception in ScopedUnlock
destructor.
Defined as:
~ScopedUnlock() { mutex.lock(); }
Calls =>
void Mutex::lock() {
QPID_POSIX_ASSERT_THROW_IF(pthread_mutex_lock(&mutex));
}
which throws and terminates the application.
In my case, the ScopedUnlock dtor is called from
[qpid-cpp-0.34/src/qpid/client/amqp0_10/IncomingMessages.cpp:202]
I am using the Session object from multiple threads and I suspect the one
thread calls close() on session while another is operating on it. Is this
scenario supported?
Scoped unlock does not seem the correct approach to me. Instead of freeing a
resource in the destructor whose failure is not catastrophic, ScopedUnlock
tries to acquire a resource on exit which can fail and there is no way this can
be communicated back to the code!
I propose that the class be done away with and an explicit resource acquisition
with proper failure handling semantics be used.
-----Original Message-----
From: Sridharan, Venkatesan
Sent: Monday, October 12, 2015 10:54 AM
To: '[email protected]' <[email protected]>
Subject: Crash on inability to catch the internal exception thrown from qpid
c++ API
Hi Folks,
While debugging an application crash in a client program using qpid c++ API, I
traced the root cause of the error to the fact that an internal exception
(qpid::Exception) which is not exposed in the API was thrown. The exception
was in Mutex.h:116 locking code. I had coded an error recovery part of the
code and looks like:
// qpid::messaging::Connection m_conn;
// qpid::messaging::Session m_session
try
{
if (m_session.hasError())
{
m_session.close();
m_conn.close();
LOG(WARNING) << "Session has errors, recreating...";
m_conn.open();
m_session = m_conn.createSession();
}
}
catch(std::exception const& ex)
{
..
}
catch(...)
{
..
}
Exception is not caught in both the catch() blocks.
This is because there are places in the control flow where a Mutex object is
locked but the internal exception thrown is not captured. This leads to leak of
internal exception and since it is not exposed in the API, gcc cannot get its
typeinfo for exception handling and terminate() gets called. Since the issue
is with the QPid API, I am powerless to prevent crashes in my application.
Using two exception hierarchies and leaking internal exceptions is bug prone
and I think we should expose all the exception types (including internal) in
the API so as to not crash the clients using the API. What is the consensus
here on exposing ALL the exceptions qpid client API might possibly throw? Or am
I missing something?
Cheers
Venkatesan
Confidentiality Note: This e-mail and any attachments are confidential and may
be protected by legal privilege. If you are not the intended recipient, be aware
that any disclosure, copying, distribution or use of this e-mail or any
attachment is prohibited. If you have received this e-mail in error, please
notify us immediately by returning it to the sender and delete this copy from
your system. Thank you for your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
