From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20051118 Fedora/1.5-0.5.0.rc3 Firefox/1.5 Description of problem: The code for internal testcase rt/tst-timer.c, which is in nptl/sysdeps/pthread/tst-timer.c, contains races between the timer expirations and the calls to timer_delete() at lines 139 through 152. The delivery of the signal when a timer expires can be delayed arbitrarily, and the calls to intr_sleep(3) provide no synchronization. Because of this, the timer thread can access the timers after they have been free()d by timer_delete(). ==4295== Thread 3: ==4295== Invalid read of size 8 ==4295== at 0x4A10FF3: timer_sigev_thread (timer_routines.c:46) ==4295== by 0x4B2A84B: start_thread (pthread_create.c:261) ==4295== by 0x4D0527C: clone (in /home/jreiser/rpmbuild/BUILD/glibc-20051119T1959/build-x86_64-linuxnptl/libc.so) ==4295== Address 0x4E77238 is 16 bytes inside a block of size 80 free'd ==4295== at 0x49055B3: free (vg_replace_malloc.c:235) ==4295== by 0x4A0FCF3: timer_delete@@GLIBC_2.3.3 (timer_delete.c:63) ==4295== by 0x400CC5: main (tst-timer.c:152) Version-Release number of selected component (if applicable): glibc-2.3.90-18 How reproducible: Sometimes Steps to Reproduce: 1. Run internal testcase rt/tst-timer under valgrind-3.1.0. 2. 3. Actual Results: timer_thr2 can be accessed after it has been free()d by timer_delete(). Expected Results: No access to a timer after it has been free()d by timer_delete(). Additional info: Low severity because the testcase still covers functionality in most cases.
That's not a bug, glibc testsuite relies in many places on certain effects happening within reasonable time, you shouldn't be running the testsuite on extremely slow or extremely busy boxes. While most of the functionality that needs testing can be tested by tests with complete synchronization, some things simply can't be tested that way.