On 10/29/2015 06:14 AM, Sridharan, Venkatesan wrote:
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
First off, I apologise for not replying to earlier mails. I meant to try
and reproduce myself, but didn't get the time to do so.
I tend to agree with you that the ScopedUnlock is a little unsafe.
However in your patch, you use lambdas which though very neat would not
work on older compilers.
One option (not as neat, admittedly) would be to use boost::function
instead (which is already used elsewhere in the codebase).
In terms of the original issue, i.e. if the object to which the lock
instance is scoped is being deleted while still in use by active
threads, I think that may require some higher level fix.
As for process, attaching to a JIRA is fine. There is also a reviewboard
instance which is quite nice, as it allows easy discussion of specific
parts of the proposals: https://reviews.apache.org
-----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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
