Bug 2956 - test(frysk.proc.StressAttachDetachRapidlyCloningMainTask)junit.framework.AssertionFailedError: event loop run explictly stopped (startChild (Sig_HUP))
Summary: test(frysk.proc.StressAttachDetachRapidlyCloningMainTask)junit.framework.Asse...
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Blocks: 1553
  Show dependency treegraph
Reported: 2006-07-22 15:03 UTC by Mark Wielaard
Modified: 2007-07-31 20:34 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

./TestRunner -c FINE frysk.proc.StressAttachDetachRapidlyCloningMainTask log (859 bytes, text/plain)
2006-07-22 15:04 UTC, Mark Wielaard

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2006-07-22 15:03:57 UTC
This frysk-core test regularly fails for me. I'll attach a TestRunner -c FINE log.
Comment 1 Mark Wielaard 2006-07-22 15:04:45 UTC
Created attachment 1177 [details]
./TestRunner -c FINE frysk.proc.StressAttachDetachRapidlyCloningMainTask  log
Comment 2 Mark Wielaard 2007-02-02 13:41:18 UTC
This stress tests seems to behave a lot better now. But occasionally it gets
into some loop and doesn't stop at all. This however seems unrepeatable with -c
FINE (sigh).
Comment 3 Andrew Cagney 2007-02-02 15:24:11 UTC
A loop (with CPU usage pegged) or a hang (sitting in the event loop or waitpid)?
Comment 4 Mark Wielaard 2007-02-02 15:32:05 UTC
CPU usage pegged
Comment 5 Andrew Cagney 2007-02-02 20:59:54 UTC
Sorry, should be more precice.  CPU pegged by the test program or frysk, i.e.,
is frysk sleeping?
Comment 6 Andrew Cagney 2007-07-31 20:34:01 UTC
I'm going to assume that this is from the CLASSPATH pattern matcher (which is
really really slow).

Typically, on a 1.1ghz i386 I need to specify --timeout 30 to prevent the timeout.