Bug 61353 - Sharing pthread mutexes between threads, that are created recursively by the new threads, cause segmentation faults.
Sharing pthread mutexes between threads, that are created recursively by the ...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-18 07:53 EST by Juha Torkkel
Modified: 2016-11-24 09:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 14:38:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cpp-source file and Makefile for building it (1.74 KB, application/x-tar-gz)
2002-03-18 07:55 EST, Juha Torkkel
no flags Details

  None (edit)
Description Juha Torkkel 2002-03-18 07:53:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
The linux threads library seems to segfault when sharing mutexes between threads
that are created recursively. The routine that I used to display this bug goes
as follows:

1) Create a thread that has atomic variable protected by a mutex
2) use the parent thread for atomically changing a variable and condvar for
signalling the change
3) on receival of the signal the child thread will create a new child that will
act in a similar manner.

Loop that rapidly for a while and linux threads will do a segmentation fault.
See the attached code that runs smoothly on solaris.

I managed to reproduce the problem on atleast:
2.4.2-2 kernel, 2.2.4-13 glibc
2.4.9-31 kernel, 2.2.4-19.3 glibc
2.4.17 kernel, 2.2.4-19.3 glibc
2.4.9-21smp kernel, 2.2.4-19.3 glibc

On SMP machine segmentation faults were not as common, but pthread_mutex calls
failed with EINVAL although everything should've been in order.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. compile the accompanied example
2. execute the compiled binary at CLI in while loop
3. see the segmentation faults happend.
	

Additional info:
Comment 1 Juha Torkkel 2002-03-18 07:55:44 EST
Created attachment 48845 [details]
cpp-source file and Makefile for building it
Comment 2 Juha Torkkel 2002-03-19 02:55:20 EST
There is a bug in the tester itself. In main() the parent_thread thr_handle is within the stack. Once the main exits the handle is freed although threads that are still running use the handle. This obiviously causes the segmentation faults.

I will look in more depth in order to figure out, wether the bug is valid or not...
Comment 3 Alan Cox 2002-12-15 14:38:29 EST
Works for in 3.2

Note You need to log in before you can comment on or make changes to this bug.