This is the mail archive of the
mailing list for the frysk project.
Re: Race condition with AckDaemonProcess
- From: Adam Jocksch <ajocksch at redhat dot com>
- To: Andrew Cagney <cagney at redhat dot com>
- Cc: frysk <frysk at sources dot redhat dot com>
- Date: Fri, 28 Jul 2006 11:10:44 -0400
- Subject: Re: Race condition with AckDaemonProcess
- References: <44C7CE23.email@example.com> <44CA2910.firstname.lastname@example.org>
Andrew Cagney wrote:
Adam Jocksch wrote:
I think I've resolved this issue. The test program I was using was
reaching the kill call before frysk was ready to recieve it. I've
changed the test program and it seems to work now, although I'll be
watching closely for it's recurrance.
I've been using AckDaemonProcess to write the test case for the stack
trace work I've been doing, and I've recently stumbled upon an
interesting race condition.Something must be causing it to miss or drop the ack signal :-/ Does
it work when just that test is run from within the test framework?
What does ftrace show?
I'm telling AckDaemonProcess to launch a program called looper2 (that
I've checked the source for into frysk-core/rt/tests/) that makes a
few function calls to establish some sort of meaningful context, then
signals Frysk to continue and busywaits while frysk attaches to it.
When I build this file outside of the build system using just -g the
daemon process returns right away and the test continues as normal.
However since moving looper2 into the build system I find that the
AckDaemonProcess constructor times out whenever the test case is run
without logging. Running the test case with logging (i.e. with -c
FINE) allows the test case to run normally again, which is what leads
me to believe that there is a race condition somewhere.
I'll be looking into this, but if anyone has any insights they'd like
to share they would be very welcome :)