I am getting a debug abort when I try to use std::lock_guard

Question

I am getting a debug abort when I try to use std::lock_guard

Friesen, Stanley 21

I am unable to determine the cause of a debug abort in the std::lock_guard constructor. _Mtx_lock() is returning a value of 3. I have no idea what that means.
In the class definition I have a member declared:
std::mutex _mutex;
In a member function I have:
std::lock_guard lck(_mutex);

I have verified that the constructor for my class is being called, so the mutex should have been initialized.

How do I determine how to fix my code?

Accepted answer

0 additional answers

Your answer

Answer 1

RLWA32 49,541

Maybe the problem is something like what was described here - https://stackoverflow.com/questions/30741114/stdmutexlock-fails-on-windows-error-code-3

Friesen, Stanley 21 Reputation points

2021-06-15T14:21:07.34+00:00

That does seem to be the error. But I find this worrisome as the lock_guard instantiation is not in a recursive context. The call stack does not pass through any other function that locks that mutex. It should not be locked. Also, when I try an unlock() before the lock_guard the abort occurs in the unlock call instead.

This is beginning to sound like an uninitialized mutex, despite my verification that the containing class's constructor has been called. Is there some way to verify if a mutex has been initialized properly?
Friesen, Stanley 21 Reputation points

2021-06-15T14:46:39.397+00:00

Now I think the mutex must have gotten corrupted somehow. There is a prior use of the mutex like so:
void *ptr = nullptr;
std::unique_lock lck(_mutex);
if (!found)
{
// Need a new instance
lck.release();
ptr = new Stuff;
}
else
{
ptr = cache.front();
cache.pop_front();
}

return Thing(ptr);

This function has returned by the time the other function is called. Could this have corrupted the mutex?
RLWA32 49,541 Reputation points

2021-06-15T15:40:49.107+00:00

The error code 3 means that the mutex is already owned. Perhaps some other code is using the mutex and is failing to unlock it before the function using lock_guard is called.
Friesen, Stanley 21 Reputation points

2021-06-15T15:42:41.127+00:00

Then unlock would have patched over the problem instead of aborting.
RLWA32 49,541 Reputation points

2021-06-15T15:52:22.877+00:00

For diagnostic purposes have you tried testing the mutex in the member function instead of unconditionally locking with lock_guard?
Friesen, Stanley 21 Reputation points

2021-06-15T16:12:18.64+00:00

It turns out it was the call to lck.release() that was causing the problem. That was the wrong function for that use. I really wanted lck.unlock().

Share via

I am getting a debug abort when I try to use std::lock_guard

0 additional answers

Your answer