Bug 174595

Summary: tst-timer.c races between timer_delete() and timer thread
Product: [Fedora] Fedora Reporter: John Reiser <jreiser>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 5   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-30 16:19:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Reiser 2005-11-30 15:49:51 UTC 
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.
Comment 1 Jakub Jelinek 2005-11-30 16:19:09 UTC 
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.