Bug 174595 - tst-timer.c races between timer_delete() and timer thread
Summary: tst-timer.c races between timer_delete() and timer thread
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: 5
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
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:
Story Points: ---
Clone Of:
Last Closed: 2005-11-30 16:19:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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):

How reproducible:

Steps to Reproduce:
1. Run internal testcase rt/tst-timer under valgrind-3.1.0.

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.