This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- From: "carlos at systemhalted dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 16 Feb 2012 16:32:43 +0000
- Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- Auto-submitted: auto-generated
- References: <bug-13690-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13690
--- Comment #10 from Carlos O'Donell <carlos at systemhalted dot org> 2012-02-16 16:32:43 UTC ---
(In reply to comment #9)
> For all bugs like this, I suspect hitting the race condition will require
> running the test case for months or years. That's part of why bugs like this
> are so frustrating: imagine your mission-critical system crashing just a couple
> times a year and the crash not being reproducible. It might be easier to hit
> the race with some extreme usage of scheduling priorities to prevent the
> unlocking thread from executing for a long time.
I agree, but a test case need not be an exact representation of your
application under test.
The trick I normally use is to preload an auditing library and use the
plt_enter and plt_exit stubs to slow down a thread, widening the race window or
in some cases making it a 100% reliable reproducer.
Such a trick is a perfectly acceptable way to make a test case, but might be
hard to use in this situation.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.