Bug 3927

Summary: FryskHelpManager initial startup causes backtrace
Product: frysk Reporter: Rick Moseley <rmoseley>
Component: generalAssignee: Unassigned <frysk-bugzilla>
Status: NEW ---    
Severity: normal CC: cagney
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 2248    

Description Rick Moseley 2007-01-26 14:51:42 UTC
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
Comment 1 Andrew Cagney 2007-01-29 17:10:09 UTC
I think I know whats happening, and wow, that means frysk's core is being pretty

- 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

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.
Comment 2 Rick Moseley 2007-01-31 21:15:47 UTC
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

{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.
Comment 3 Andrew Cagney 2007-01-31 21:39:13 UTC
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.