Bug 1988

Summary: Exec observer instability
Product: frysk Reporter: Phil Muldoon <pmuldoon>
Component: generalAssignee: Stan Cox <scox>
Severity: normal CC: cagney, swagiaal
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 1418    

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 ***