Bug 5735

I noticed that the test before it:

    public void testCoreExeCommand() {
	File exe = Config.getPkgLibFile("funit-hello");
	File core = CorefileFactory.constructCoreAtSignal(exe);
	e = new HpdTestbed();
	e.sendCommandExpectPrompt(("core " + core.getPath()
				   + " " + exe.getPath()),
				  "Attached to core file.*");
    }

Was essentially the same as the testCoreThenRunCommand, other than this
additional line in the testCoreThenRunCommand:

	e.sendCommandExpectPrompt("run",
				  "Attached to process.*");

On removing this the test files passes 100 out of 100 runs.

The whole of the test is:

    public void testCoreThenRunCommand() {
	File exe = Config.getPkgLibFile("funit-hello");
	File core = CorefileFactory.constructCoreAtSignal(exe);
	e = new HpdTestbed();
	e.sendCommandExpectPrompt(("core " + core.getPath()
				   + " " + exe.getPath()),
				  "Attached to core file.*");
	e.sendCommandExpectPrompt("run",
				  "Attached to process.*");
    }

Looking at the live load/run case in TestRunCommand.java, which is testing the
same functionality the test is differently constructed. Not the different expect
output and the thread.sleep(). I'll convert the corefile test to this one to see
if it passes with the different expect, and thread.sleep().

    public void testRunCommand() {
	e = new HpdTestbed();
	e.sendCommandExpectPrompt("load " +
Config.getPkgLibFile("funit-threads-looper").getPath(),
	"Loaded executable file.*");
	e.sendCommandExpectPrompt("run ",
		"Attached to process ([0-9]+).*Running process ([0-9]+).*");
	try { Thread.sleep(1000); } catch (Exception e) {}
	e.sendCommandExpectPrompt("focus","Target set.*\\[0\\.0\\]\t\t([0-9]+)" +
		"\t([0-9]+)\r\n" + "\\[0\\.1\\]\t\t([0-9]+)\t([0-9]+)\r\n");
	e.send("quit\n");
	e.expect("Quitting\\.\\.\\.");
	e.close();
    }

Altering the test has no effect. However I was investigating the cause of EOF.
Adding in a System.out.println into frysk.expunit.Child and the function:
expectMilliseconds:

	    System.out.print("Expect output: " + output);
	    if (eof) {
		fine.log(this, "match EOF");
		throw new EndOfFileException(matches, output);
	    }

I get the output:

Expect output: run 
Attached to process 11658
starting/running with this command:
/home/pmuldoon/frysk_bin/frysk-core/frysk/pkglibdir/funit-hello 
Exception in thread "main" starting/running with this command:
/home/pmuldoon/frysk_bin/frysk-core/frysk/pkglibdir/funit-hello 
java.util.ConcurrentModificationException
   at java.util.LinkedList$LinkedListItr.checkMod(libgcj.so.8rh)
   at java.util.LinkedList$LinkedListItr.remove(libgcj.so.8rh)
   at frysk.hpd.CLI.flushMessages(fhpd)
   at frysk.hpd.CLI.execCommand(fhpd)
   at frysk.bindir.fhpd.main(fhpd)
FAIL
  junit.framework.AssertionFailedError: sent: <run > expecting: <Attached to
process ([0-9]+).*Running process ([0-9]+).*> got: <EOF>

Looking at flushmessages() in CLI.java:

    private void flushMessages() {
        for (Iterator iter = messages.iterator(); iter.hasNext();) {

I see the use of a fail-fast iterator. I suspect that in the SteppingEngine, the
injection of:

Task 10858 is terminating from signal SIGSEGV(11)

Is causing a concurrent modification exception and causing an EOF

Removing the injection of this message from frysk.step.SteppingEngine in
updateTerminating:

	    tse.setState(new StepTerminatedState(task, true));
	    if (signal != null)
		tse.setMessage(tse.getMessage()
			       + "Task " + task.getTid()
			       + " is terminating from signal " + signal);
	    else
		tse.setMessage(tse.getMessage()
			       + "Task " + task.getTid()
			       + " is exiting with status " + value);

	    steppingObserver.notifyNotBlocked(tse);

and the test passes. Looking at why, through the eventual change of execution:

Inside frysk/hpd/CLI.java, in the class SteppingObserver we see:

       public void update (Observable observable, Object arg) {
            TaskStepEngine tse = (TaskStepEngine) arg;
            if (!tse.isAlive()) {
		addMessage(tse.getMessage(), Message.TYPE_VERBOSE);
		tse.setMessage("");
		flushMessages();

If another message (say from the run command) alters the output of the message
buffer during flush, the concurrent exception error seems to happen.

Created attachment 2231 [details]
Synchronize access to output buffer patch

This patch fixes the bug