I have created the JIRA: https://issues.apache.org/jira/browse/QPID-6811 for the issue.
I have attached a patch to the JIRA, am new to qpid development process, not sure how to go about it - can anybody provide some pointers on how to take this patch forward? Tested on Linux and Windows Thanks, Venkatesan -----Original Message----- From: Sridharan, Venkatesan Sent: Friday, October 16, 2015 4:06 PM To: '[email protected]' <[email protected]> Subject: RE: Crash on inability to catch the internal exception thrown from qpid c++ API 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]
