Bug 3927 - FryskHelpManager initial startup causes backtrace
Summary: FryskHelpManager initial startup causes backtrace
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Blocks: 2248
  Show dependency treegraph
Reported: 2007-01-26 14:51 UTC by Rick Moseley
Modified: 2007-01-31 21:39 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
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.