[
https://issues.apache.org/jira/browse/AMQCPP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQCPP-490.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.8.0
3.7.1
Test added with thanks. Seems fine now with latest fixes. Open a new issue if
you find others, we love more tests.
> Exception lifetime confusion can cause the application to crash
> ---------------------------------------------------------------
>
> Key: AMQCPP-490
> URL: https://issues.apache.org/jira/browse/AMQCPP-490
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl, Decaf
> Affects Versions: 3.5.0, 3.6.0, 3.7.0
> Reporter: Jonathan Fortier
> Assignee: Timothy Bish
> Fix For: 3.7.1, 3.8.0
>
> Attachments: Test-AMQCPP-490.patch
>
>
> In changeset #139775, the "decaf::lang::Exception" class changed its
> ownership policy for its std::exception cause. Before the changeset,
> Exception class would clone the cause, and after the change, the Exception
> class took ownership of the std::exception.
> However, many code paths still assume that the Exception class will clone the
> std::exception, which makes the application crash when a std::exception is
> thrown in their protected region.
> Here is a incomplete list of places in the code that makes this bad
> assumption (line numbers from version 3.7.0):
> -decaf\util\concurrent\FutureTask.h, line 272
> -decaf\util\concurrent\FutureTask.h, line 301
> -decaf\util\concurrent\ThreadPoolExecutor.cpp, line 742
> -activemq\core\ActiveMQTransactionContext.cpp, line 646
> -activemq\core\ActiveMQTransactionContext.cpp, line 757
> -decaf\internal\net\tcp\TcpSocket.cpp, line 361
> Note that subclasses of Exception may also be affected, since they normally
> forward the cause to their parent.
> The comments on many of those classes still wrongly indicates that the cause
> will be cloned. For example, the comments for Exception::Exception(const
> std::exception*) is inconsistent with the comments for Exception::initCause()
> An easy way to reproduce the bug is to throw a std::exception from an
> onException callback, which should make the application crash.
--
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
