Bug 174595 - tst-timer.c races between timer_delete() and timer thread
Summary: tst-timer.c races between timer_delete() and timer thread
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 5
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-30 15:49 UTC by John Reiser
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-30 16:19:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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