Why are you doubting memory corruption? This sounds almost exactly like memory corruption when a mutex that once worked later crashes.
What is the error you see on the crash? Is it a segment violation that most likely indicates a memory corruption?
How many threads are there in your application (I assume it’s multi-threaded since you are using mutex’s)? When you look at the core dump in gdb, make sure you do a ‘thread’ command to see the state of all threads. The currently running one has a * next to it. Sometimes I have found that gdb starts the core file in the wrong thread.
Assuming that the crash is in the running thread with the mutex.lock() call I’d go and look at the code/memory region where the mutex is created and see if it is truly corrupted (hex dump that memory region sometimes helps). It is especially more likely if the mutex is created on the heap instead of the stack in another thread (for example if another thread created the mutex on the heap it may have released it either on purpose or perhaps inadvertantly if that thread was itself exiting for some reason).
Also, assuming this crash is easy to reproduce, you might just run your application in the debugger to start with instead of trying to debug the core file. Then you can specifically have gdb watch the memory location of the mutex to see if its gets released/overwritten. This will make your app run REALLY slow but if you are desperate and patient it will work.