Opened 7 years ago
Closed 7 years ago
#11317 closed Support Requests (wontfix)
boost unique_lock has no mutex
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | To Be Determined | Component: | thread |
Version: | Boost 1.58.0 | Severity: | Problem |
Keywords: | boost unique_lock has no mutex | Cc: |
Description
This is an issue I am observing in the newly released boost_1_58 library. I suspect the problem may not be boost related, and could be an msvc 12.0 compiler related issue. The symptom I observe is that when a Visual C++ project TURNS ON one of the compiler optimization flags /Og, /O1, /O2 or /Ox Flags, the C++ code that I am using below is throwing an exception:
Below is the sample code I use in the application:
boost::mutex::scoped_lock <Scoped Lock Variable> (<Mutex Object>)
Below is the exception message I am seeing which strangely occurs the second time a scoped lock is called on the same valid Mutex Object within the application:
"boost unique_lock has no mutex"
I am baffled by what causes this problem. When I turn off the optimization flags and execute the program, the application executes flawlessly. Only when I turn on optimization flags, this error consistently occurs. Workaround I am using is to disable optimization Flags for the release version.
Below is my build configuration:
Visual Studio community edition 2013, which uses msvc 12 compiler version; Windows 8.1; boost Library version 1.58
Change History (6)
follow-up: 3 comment:1 by , 7 years ago
comment:2 by , 7 years ago
Component: | None → thread |
---|---|
Owner: | set to |
Status: | new → assigned |
Type: | Bugs → Support Requests |
comment:3 by , 7 years ago
Replying to viboes:
I would need more context, but I suspect that you are moving a unique_lock and then you are locking it.
How optimization change the behavior of your application is out of my understanding.
vibeos,
Heres a sample code snippet that can be used to reproduce this issue on msvc 12.0:
#include <boost/thread.hpp>
class MyClass {
boost::mutex myboostmutex;
public:
void Function1(); void Function2();
}
void MyClass::Function1() {
boost::mutex::scoped_lock SomeVariable (myboostmutex);
Application code
}
void MyClass::Function2() {
boost::mutex::scoped_lock SomeVariable (myboostmutex);
Application code
}
To reproduce this bug, you need to follow these steps:
1) Compile code with one of the flags /Og, /O1, /O2 or /Ox Flags (TURNED ON) in msvc 12.0 compiler. 2) Create an instance of MyClass; 3) First invoke Function1(), it should execute without any issue. 4) Next execute Function2().
When the code attempts to execute the boost::mutex::scoped_lock SomeVariable(myboostmutex) line in Function2() You can see a runtime exception "boost unique_lock has no mutex". The same erroneous behaviour doesn't occur when you turn off all the above mentioned compiler optimization flags.
I would recommend trying to compile boost 1_58 library on an older version msvc 10.0 or msvc 11.0 compiler. That can help isolate the problem to determine if this is related to the compiler version.
Thanks, Shyam
follow-up: 5 comment:4 by , 7 years ago
Hi, I would let you report this misbehavior to the compiler vendor and try with other versions of Boost or the compiler ;-)
I don't see any problem with the Boost library here.
Except if Nial wants to try, I would propose to close this ticket as invalid.
comment:5 by , 7 years ago
Replying to viboes:
Hi, I would let you report this misbehavior to the compiler vendor and try with other versions of Boost or the compiler ;-)
I don't see any problem with the Boost library here.
Except if Nial wants to try, I would propose to close this ticket as invalid.
Hi,
My two cents to this would be to hold off closing the ticket untill the code was tested with another version of the compiler by someone. The results I have gathered were from msvc 12.0 because that is the only compiler I have with me.
-Shyam
comment:6 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Unfortunately I have none
I would need more context, but I suspect that you are moving a unique_lock and then you are locking it.
How optimization change the behavior of your application is out of my understanding.