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) (/home/pmuldoon/workspace/frysk-gui/frysk/proc/State.java:70) at frysk.proc.TaskState.processPerformSignaled(frysk.proc.Task, int) (/home/pmuldoon/workspace/frysk-gui/frysk/proc/TaskState.java:98) at frysk.proc.Task$13.execute() (/home/pmuldoon/workspace/frysk-gui/frysk/proc/Task.java:393) at frysk.event.EventLoop.runEventLoop(boolean) (/home/pmuldoon/workspace/frysk-gui/frysk/event/EventLoop.java:311) at frysk.event.EventLoop.run() (/home/pmuldoon/workspace/frysk-gui/frysk/event/EventLoop.java:411) at frysk.gui.FryskGui$3.run() (/home/pmuldoon/workspace/frysk-gui/frysk/gui/FryskGui.java:189) at java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0)
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);
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 ***