Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 200843

Summary: bug in <sys-apps/gcc-4.2.0 which affects pthread_mutex_lock
Product: Gentoo Linux Reporter: Christopher Friedt <chrisfriedt>
Component: [OLD] Core systemAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: VERIFIED INVALID    
Severity: normal CC: loki_val, Murphy.Gebert
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Christopher Friedt 2007-11-30 15:56:49 UTC
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
Comment 1 Peter Alfredsen (RETIRED) gentoo-dev 2007-11-30 16:10:55 UTC
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)
Comment 2 Christopher Friedt 2007-11-30 16:22:25 UTC
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
Comment 3 Peter Alfredsen (RETIRED) gentoo-dev 2007-11-30 16:40:02 UTC
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.
Comment 4 Christopher Friedt 2007-11-30 17:29:40 UTC
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.
> 

Comment 5 SpanKY gentoo-dev 2007-12-01 07:35:51 UTC
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.
Comment 6 Christopher Friedt 2007-12-01 11:24:42 UTC
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.
> 

Comment 7 Martin Gebert 2009-02-19 11:04:21 UTC
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?