There is a bug in the way that gcc reorders machine code around lll_mutex_lock. As far as I know, this is only a problem on x86 architectures, but I have no way of knowing otherwise at the moment. I have been working non-stop for the last two days convinced it was some kind of problem in my own multi-threaded code but it turns out, that it was not my error at all. Strangely, I'd been compiling and debugging the code with -O0 meaning 'no optimizations'. The error I was receiving appeared the following on stderr: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. The process was killed with signal SIGABRT by the kernel. This bug is further documented here: http://sourceware.org/ml/glibc-bugs/2006-10/msg00042.html and fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415 Reproducible: Sometimes Steps to Reproduce: Its non-deterministic - has to do with with way that code is re-ordered in a multi-threaded process. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415 Actual Results: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Expected Results: Mutex should lock. I would suggest that some version >=sys-devel/gcc-4.2.0 be marked as stable, or at least the patch be re-worked from that fixed bug below: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
The bug report states that =gcc4.1* and >=gcc-4.2.0 are not affected by that bug. It even uses gcc-4.1.1 as an example of correct code generation. Which version of gcc are you using that is in the tree as stable that is affected by this bug? (in other words, please attach emerge --info)
Actually, it says that gcc-4.1.1 generates the correct code, but I'm using the latest version of gcc marked stable for x86 in portage. That is gcc-4.1.2 I'm just about to emerge gcc-4.2.2. If the same problem persists after the emerge, then I'll know for certain that it wasn't the same problem. Although I was receiving the exact same error, line-for-line with gcc-4.1.2
http://bugs.freedesktop.org/show_bug.cgi?id=10035 I just ran across the above and it seems to be a good explanation. If I understand this correctly, it should be possible to avoid this problem by passing -lpthread to the linker unconditionally or by having a look at the patch in the cairo bug report.
I'm writing a shared library that uses threads, and testing it out with a very simple program that has about 5 lines in main(). The shared library is explicitly linked to pthreads already (-lpthread). (In reply to comment #3) > http://bugs.freedesktop.org/show_bug.cgi?id=10035 > I just ran across the above and it seems to be a good explanation. If I > understand this correctly, it should be possible to avoid this problem by > passing -lpthread to the linker unconditionally or by having a look at the > patch in the cairo bug report. >
gcc-4.2.x isnt going to go stable any time soon going by an assert message does not imply that you're experiencing the same exact bug. you could try comparing the disassembly of the functions mentioned in the report.
My apologies - I think that I was experiencing a threaded programming blunder (In reply to comment #5) > gcc-4.2.x isnt going to go stable any time soon > > going by an assert message does not imply that you're experiencing the same > exact bug. you could try comparing the disassembly of the functions mentioned > in the report. >
Hi Christopher, sorry for getting back to old issues, but as I'm currently experiencing the same symptoms, can you confirm that the problem also occurred with gcc 4.1.2?