From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: The tls implementation of pthread_detach leads to a segmentation fault. After having start 5 threads, or more, exited from all the 5 threads, the first call to pthread_detach leads to a segmentation fault. With less than 5 threads, evithing seems ok. It seems it only crashes with 5 or more. There is no problem anymore if the executable links on /lib/pthread.so istead of /lib/tls/libpthread.so.0 Version-Release number of selected component (if applicable): glib-2.3.2-27.9 How reproducible: Always Steps to Reproduce: 1.Compile (g++ -l pthread main.cpp) the code in attachment. 2.Execute it. Actual Results: Thread launched. Thread launched. Thread launched. Thread launched. Thread launched. Segmentation fault Expected Results: Thread launched. Thread launched. Thread launched. Thread launched. Thread launched. Thread #0 detached. Thread #1 detached. Thread #2 detached. Thread #3 detached. Thread #4 detached. Additional info: Rename /lib/tls into /lib/tls_ and the Segmentation fault desappears.
Created attachment 93061 [details] The code to compile and run to see the Segfmentation faults. The code launch <n> threads, wait for they all exited, and call pthread_detach on each of them. <n> can be given as a parameter to the binary. 5 is default.
Your testcase is bogus. A pthread_t handle is not valid after pthread_join, it is like accessing memory after free or FILE * stream after fclose. The implementation may fail with EINVAL if it detects invalid handle, but is not required to do so. Doing so in all cases would be extremely expensive, would mean on every pthread_detach walking down all currently joinable threads and compare pthread_detach argument with them. Furthermore, even that doesn't handle the case when a pthread_t handle is reused for another thread after pthread_join (h1, ...); pthread_create (&h2, ...); pthread_detach (h1); if h2 == h1.