Uncaught exception in ‘boost/thread/lock_guard.hpp’
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- operating-systems
Research direction
Start by reviewing boost/thread/lock_guard.hpp around line 67 and the C++11 exception specification behavior described for Boost 1.75.0. Reproduce or verify the Coverity 2020.03 finding and establish whether the destructor can terminate when unlock() throws; done requires a confirmed diagnosis and an agreed change or documentation outcome.
Written by the indexing model from the issue text.
Description
Hi,
I've just run Coverity, version 2020.03, static analysis on a program using Boost v 1_75_0
It has highlighted several potential issues one of which I will describe here.
In lock_guard.hpp on line 67 the destructor calls the unlock() method of the mutex ‘m’. The unlock() can throw an exception of type boost::lock_error. However, since the C++ 11 compiler deduces the exception specification for this constructor it will use ‘noexcept(true)’ which would be the exception specification of the hypothetical implicitly-generated destructor definition. This way, if and exception is thrown from the destructor’s body and the exception specification does not allow it to be thrown this will lead to calling unexpected() which calls terminate(). Synopsis Coverity static analysis tool highlighted this problem. In my opinion the described problem can happen. Do you think so or I am missing something?
Thanks,
Dimitar
- Dominant language
- C++
- Stars
- 213
- Forks
- 171
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/thread
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
-
Difficulty 3/5 1-2 days Newbie friendliness 42/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
google/libultrahdr#485 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
godotengine/godot#123776 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 60/100
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
ros2/common_interfaces#344 ·