Bug 1988 - Exec observer instability
Summary: Exec observer instability
Status: RESOLVED DUPLICATE of bug 1418
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Stan Cox
Depends on:
Blocks: 1418
  Show dependency treegraph
Reported: 2005-12-06 22:16 UTC by Phil Muldoon
Modified: 2006-12-08 18:57 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Phil Muldoon 2005-12-06 22:16:41 UTC
pmuldoon -> stan, cagney I checked in this code. To replicate what I did:

Start a bash terminal

type echo $$ to find the PID of the terminal

from another terminal, run frysk.

In Frysk, find the PID of the bash terminal you looked at earlier

Right Click it and add a Program Observer to it

You will get this output. You will see it correctly follows forks and execs from
the bash terminal down to the exec of firefox, but it also dies on
PerformSignalled, which is wholly unexpected. 

Run firefox from that terminal you did echo $$ to find the PID on
click : frysk.gui.monitor.ProcData@23d2410
TaskForkedObserver.updateForked() 28325
Event: ProgramWatcher

TaskExecObserver.updateExeced() bash
TaskForkedObserver.updateForked() 28326
TaskExecObserver.updateExeced() firefox
TaskForkedObserver.updateForked() 28327
TaskForkedObserver.updateForked() 28328
TaskExecObserver.updateExeced() firefox
Exception in thread "Thread-2" java.lang.RuntimeException:
Linux{frysk.proc.LinuxTask@27797d0,id={TaskId,28325},state=unattached} in state
"unattached" did not handle PerformSignaled
   at frysk.proc.State.unhandled(java.lang.Object, java.lang.String)
   at frysk.proc.TaskState.processPerformSignaled(frysk.proc.Task, int)
   at frysk.proc.Task$13.execute()
   at frysk.event.EventLoop.runEventLoop(boolean)
   at frysk.event.EventLoop.run()
   at frysk.gui.FryskGui$3.run()
   at java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0)
Comment 1 Stan Cox 2005-12-08 03:54:24 UTC
One thing I notice is if logging.level = FINEST then this fails with a SIGSEGV in 
Task frysk.proc.Host.get(TaskId id): logger.log (Level.FINE, "get task {0}\n", id);
Comment 2 Andrew Cagney 2005-12-11 16:59:27 UTC
The bug here is that an attached task has got into the <<unattached>> state; not
that the <<unattached>> state can't handle a <<signal>> event.

*** This bug has been marked as a duplicate of 1418 ***