After converting FryskHelpManager.java to use frysk.sys.Fork.daemon instead of r.exec, the initial activation(and only the initial activation) causes a backtrace, but still comes up properly. FryskHelpManager activates /usr/bin/gnome-help when the "Help" button is clicked on the first Frysk UI screen. When that button is clicked the first time the following backtrace occurs: waitpid: No child processes (process 21424) at frysk.sys.Fork.daemon(Fork.cxx:159) at frysk.sys.Fork.daemon(Fork.java:97) at frysk.gui.common.FryskHelpManager.activateHelp(FryskHelpManager.java:63) at frysk.gui.SessionManagerGui.helpSession(SessionManagerGui.java:494) at frysk.gui.SessionManagerGui$12.buttonEvent(SessionManagerGui.java:384) at org.gnu.gtk.Button.fireButtonEvent(libgtkjava-2.8.so) at org.gnu.gtk.Button.handleClick(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(Gui.java:284) at frysk.gui.FryskGui.main(FryskGui.java:88) Even thought this backtrace occurs, the proper gnome-help comes up. If the gnome-help screen is closed and the "Help" button is again clicked during the current frysk activation, no backtraces occur no matter how many times this happens. The backtrace seems to only occur on the very first activation of the gnome-help.
I think I know whats happening, and wow, that means frysk's core is being pretty agressive! - the desktop thread calls frysk.sys.Fork.daemon which: does a vfork as the first step in creating a daemon, and then does a waitpid on the child - meanwhile the core thread sees the SIGCHLD for that same waitpid and grabs it - this leaves the desktop process's waitpid with nothing to wait for, hence the error That means the core is going to need to directly handle the child create, and the help code just request it. As a way of confirming this, try using: frysk.proc.Host.requestCreateAttachedProc (String[] args, null) i.e., no observer. It should create the process and then immediatly detach from it. Perhaps a: frysk.proc.Host.requestCreateDaemonProc (String[] args) should be added.
I converted to using a call to "Manager.host.requestCreateAttachedProc(args, null);" to activate the help. It comes up OK, but now when the help is terminated I get this from the core: {frysk.proc.LinuxPtraceTask@f52690,pid=31805,tid=31805,state=detached} in state "detached" did not handle handleTerminatedEvent java.lang.RuntimeException: {frysk.proc.LinuxPtraceTask@f52690,pid=31805,tid=31805,state=detached} in state "detached" did not handle handleTerminatedEvent at frysk.proc.State.unhandled(FryskGui) at frysk.proc.TaskState.handleTerminatedEvent(FryskGui) at frysk.proc.Task.processTerminatedEvent(FryskGui) at frysk.proc.LinuxPtraceHost$PollWaitOnSigChld$5.terminated(FryskGui) at frysk.sys.Wait.waitAllNoHang(FryskGui) at frysk.proc.LinuxPtraceHost$PollWaitOnSigChld.execute(FryskGui) at frysk.event.EventLoop.runEventLoop(FryskGui) at frysk.event.EventLoop.run(FryskGui) at frysk.gui.Gui$4.run(FryskGui) at java.lang.Thread.run(libgcj.so.7) I suspect passing a "null" in as the type of observer to attach is throwing it off. Looks like we do need a frysk.proc.Host.requestCreateDaemonProc (String[] args) method.
That's a new and obscure bug. If a child process (not a daemon, not a random process) becomes detached and then exits, frysk gets confused. It occures because frysk still gets the waitpid event for the child's exit, even though frysk isn't attached.