When an observer fires for gedit process - Frysk traps it, but then exceptions Related to: http://www.sourceware.org/bugzilla/show_bug.cgi?id=2803 If an observer (e.g., exit notification) is configured to gedit, the observer correctly traps the process exiting (see attachment 1 [details]). If the user opts to block the exit, this exception is raised: {frysk.proc.LinuxTask@69169c0,pid=16894,tid=16894,state=destroyed} in state "destroyed" did not handle handleUnblock frysk.proc.State.unhandled(FryskGui) frysk.proc.TaskState.handleUnblock(FryskGui) frysk.proc.Task$2.execute(FryskGui) frysk.event.EventLoop.runEventLoop(FryskGui) frysk.event.EventLoop.run(FryskGui) frysk.gui.Gui$3.run(FryskGui) java.lang.Thread.run(libgcj.so.7) If the user opts to continue and not block the exit, this exception is raised (in a Dialog): {frysk.proc.LinuxTask@636540,pid=16916,tid=16916,state=destroyed} in state "destroyed" did not handle handleUnblock frysk.proc.State.unhandled(FryskGui) frysk.proc.TaskState.handleUnblock(FryskGui) frysk.proc.Task$2.execute(FryskGui) frysk.event.EventLoop.runEventLoop(FryskGui) frysk.event.EventLoop.run(FryskGui) frysk.gui.Gui$3.run(FryskGui) java.lang.Thread.run(libgcj.so.7) And a large number of these exceptions are written to the console from which Frysk was started: java.lang.RuntimeException: Observer [frysk.gui.monitor.ListView@13179b0] is trying to add itself twice at frysk.gui.monitor.GuiObservable.addObserver(FryskGui) at frysk.gui.monitor.ListView.add(FryskGui) at frysk.gui.monitor.ListView.add(FryskGui) at frysk.gui.monitor.ListView$ItemAddedObserver.update(FryskGui) at java.util.Observable.notifyObservers(libgcj.so.7) at frysk.gui.monitor.GuiObservable.notifyObservers(FryskGui) at frysk.gui.monitor.ObservableLinkedList.add(FryskGui) at frysk.gui.monitor.GuiProc.add(FryskGui) at frysk.gui.sessions.DebugProcess.removeProc(FryskGui) at frysk.gui.sessions.DebugProcess$2.update(FryskGui) at java.util.Observable.notifyObservers(libgcj.so.7) at frysk.gui.monitor.GuiObservable.notifyObservers(FryskGui) at frysk.gui.monitor.ObservableLinkedList.remove(FryskGui) at frysk.gui.monitor.datamodels.FlatProcObservableLinkedList$ProcDestroyedObserver$2.run(FryskGui) at org.gnu.glib.CustomEvents.runEvents(libgtkjava-2.8.so) at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so) at org.gnu.gtk.Gtk.main(libgtkjava-2.8.so) at frysk.gui.Gui.gui(FryskGui) at frysk.gui.FryskGui.main(FryskGui) (see attachment 2 [details])
Created attachment 1104 [details] Screen shot 1
Created attachment 1105 [details] Screen shot 2
Additional note - the user is also presented with a series of dialogs asking him to continue or quit - you have to respond to several of these in sequence to clear the problem.
As of this morning I do not see the (Jun 23): And a large number of these exceptions are written to the console from which Frysk was started: java.lang.RuntimeException: Observer [frysk.gui.monitor.ListView@13179b0] is trying to add itself twice at frysk.gui.monitor.GuiObservable.addObserver(FryskGui) I do see the unhandled core state issues though
Update - Frysk as built from CVS on June 21 - on FC5 - when gedit is closed, the exit notification is trapped, the user is presented with a dialog to block or to close the process, accepting to close gedit results in a dialog with this being displayed: {frysk.proc.LinuxTask@d41f60,pid=9103,tid=9103,state=destroyed} in state "destroyed" did not handle handleUnblock frysk.proc.State.unhandled(FryskGui) frysk.proc.TaskState.handleUnblock(FryskGui) frysk.proc.Task$2.execute(FryskGui) frysk.event.EventLoop.runEventLoop(FryskGui) frysk.event.EventLoop.run(FryskGui) frysk.gui.Gui$3.run(FryskGui) java.lang.Thread.run(libgcj.so.7)
I'm also seeing the same behavior in comment #5 on RHEL4
Verified that this bug is fixed - the exception is not raied - as of Frysk built from CVS head on 20060629.
Fixed by this: 2006-06-27 Andrew Cagney <cagney@redhat.com> Phil Muldoon <pmuldoon@redhat.com> Sami Wagiaalla <swagiaal@redhat.com> * TestTaskObserverBlocked.java (testRefreshAfterUnblockedForkExits): New test. * TaskState.java: In "detachedBlocked" state, remember to transition to "detached" when the last blocking observer is removed.
No, the change quoted in comment #8, cannot by itself be the fix. The problem has been reproduced on RHEL 4 with 2006-06-28 build, which contained the change. But it did not manifest itself on an FC5 system. (Reported by Len.) Since then, the RHEL 4 rpm contains a workaround patch (by Sami). It seems this should be verified once more, with a ``clean'' build on RHEL 4.