Bug 174595 - tst-timer.c races between timer_delete() and timer thread
tst-timer.c races between timer_delete() and timer thread
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
5
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-30 10:49 EST by John Reiser
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-30 11:19:09 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)

  None (edit)
Description John Reiser 2005-11-30 10:49:51 EST
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 11:19:09 EST
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.