bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glibc-2.3.2 : broken pthreads


From: Carlo Wood
Subject: glibc-2.3.2 : broken pthreads
Date: Thu, 15 May 2003 02:15:14 +0200
User-agent: Mutt/1.4.1i

After upgrading to glibc-2.3.2 (from 2.2.93),
the testsuite of libcwd suddenly started to
show errors for the threaded test cases.

After investigation I became convinced that
this is caused by different threads locking
the same mutex simultaneously.

Consider the following debug output:

CWDEBUG_DEBUG: 32771: locking mutex 45 (0x400e12d8) from 0x400cb546 from 
0x400c9e22
CWDEBUG_DEBUG: 32771: Lock 45 obtained (0x400e12d8).
CWDEBUG_DEBUG: 32771: mutex_tct::lock(): instance_locked[45] == 0; incrementing 
it.
CWDEBUG_DEBUG: 16386: locking mutex 45 (0x400e12d8) from 0x4009dfba from 
0x400b0c0c
CWDEBUG_DEBUG: 16386: Lock 45 obtained (0x400e12d8).
CWDEBUG_DEBUG: 16386: mutex_tct::lock(): instance_locked[45] == 1; incrementing 
it.
CWDEBUG_DEBUG: 16386: mutex 45 (0x400e12d8) is already set by another thread 
(32771)!

This debug output is written by calls to the
unbuffered system call write(2), using fd 2.

The values 32771 and 16386 are two ids as
returned by pthread_self() and indicate two
different threads.

The address 0x400e12d8 is the pointer to
the pthread_mutex_t being used, that is
being passed to the involved functions
`pthread_mutex_lock' and `pthread_mutex_unlock'.
It proves that 'mutex 45' is one and the same mutex
(being a private, static member of a class
that cannot be accessed else where in the code).
(The '45' is a integer template parameter,
determining the instance of the static member).

The output "Lock 45 obtained" is printed
directly after calling `pthread_mutex_lock',
inside the critical area of this mutex thus.

Just prior to calling `pthread_mutex_unlock',
the code prints "unlocking mutex 45 (0x400e12d8)".
Because this is not printed in the above output
snippet, we can conclude that thread 32771 is
still in the critical area of this mutex and
still has this mutex locked.

Nevertheless, thread 16386 passed successfully
the call to `pthread_mutex_lock' for this mutex
while thread 32771 has it locked.

My questions:

1) Is this a known issue?
2) Do you have suggestions of what I could do
   to further investigate this?

Don't tell me to write a small test case :).
That would mean that you never wrote a small
test case for this - and if you did, then I
assume it will work in that case.

Maybe you would be interested to reproduce this
yourself with the libcwd sources.  I can send
you instructions for this.

Environment info:

>uname -a
Linux ansset 2.4.20-tcore-akpm-preempt #2 Thu Apr 3 14:54:29 CEST 2003 i686 
athlon i386 GNU/Linux

Compiler used (compiled myself):
>g++-3.2.3 -v
Reading specs from 
/usr/local/gcc-3.2.3/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: /usr/src/gcc/gcc-3.2.3/configure --prefix=/usr/local/gcc-3.2.3 
--enable-shared --with-gnu-as --with-gnu-ld --enable-languages=c++ 
--enable-debug --enable-threads=posix --disable-checking --with-system-zlib 
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3

>rpm -q binutils
binutils-2.13.90.0.20-7

This is compiled by myself, the ones provided
by redhat (rawhide) didn't work at all:
>rpm -q glibc
glibc-2.3.2-37


Waiting for instructions,

-- 
Carlo Wood <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]