New builds of a monitor process I use have started throwing this error:
/home/william/libcxx-3.4/src/mutex.cpp:84: std::__1::recursive_mutex::~recursive_mutex(): Assertion `e == 0' failed.
Nothing I do will resolve this. The only changes between a working build and any new builds are both minimal and unrelated to the mutex. The changes aren’t even in the same class. I’ve tried removing the file from /tmp, but it makes no difference.
I’m essentially dead in the water now. I can’t make new builds. This is an x86-64 Ubuntu 22.04 system.
Have you purged Xojo’s caches?
Have you tried the needful:
- Rebooted the computer
- Tried another user on the same computer
- Tried another computer
A recursive_mutex can be locked multiple times by the same thread and MUST be unlocked the same number of times so it can be destroyed. Looks like there’s some unbalance.
It can be at framework level dealing with the resource locking used by the framework, not related to Xojo Mutex, at user level I guess they could be more associated to parts of code using CriticalSections or Semaphores than Mutexes in Xojo.
So after lots of frustration, it turns out this was an unhandled database exception. For some reason the typical exception output wasn’t being dumped, the process would just end, and the mutex error appears instead. No idea why.
3 Likes
Not properly cared exceptions are a known cause of some bugs related to missing the pairing of lock/unlock of resources (specially in re-entrant code) and at some point like some end of scope a critical-section or semaphore would be released under such broken condition firing the assertion.
A mutex error in a db enviroment means that your function etc is vulnerable to hacking as its access point is not limited to a specific scheme, such as auth / public etc.
This is not always an error, (postgres) raises this as a warning and then you can just recreate the function and glue it to a specific scheme :
Example:
Instead of creating functtion “my_function”
You create “auth.my_function”
Same applies to tables and access rules.
This will lead to a mutex error / warning
The database error and mutex error are not directly related. It’s a Xojo DatabaseException, in this case due to a schema change I had forgotten to apply, and the Xojo framework failing to do its job correctly. For a reason I can’t explain, the exception data was not output, and the mutex error happened while the process was stopping. This was a Xojo Mutex class instance. It’s really not that complicated, just the framework misbehaving.
1 Like