Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpl-opus!hpnmdla!darrylo
From: darrylo@hpnmdla.HP.COM (Darryl Okahata)
Newsgroups: comp.sys.hp
Subject: Re: Motif and xdb problem
Message-ID: <430024@hpnmdla.HP.COM>
Date: 20 Sep 90 16:36:11 GMT
References: <9474@uhccux.uhcc.Hawaii.Edu>
Organization: HP Network Measurements Div, Santa Rosa, CA
Lines: 89

In comp.sys.hp, john@quonset.cfht.hawaii.edu (John Kerr) writes:

> Can anyone give me a clue about this problem:
> 
> I am debugging a Motif 1.0 application with xdb on an HP9000s350.
> Whenever I execute XmCreateFileSelectionDialog, I get this message --
> 
>    death of child (no ignore) at 0xa1ff0
>    (file unknown): _sigprocmask +0x8: (line unknown)
> 
> I can continue the program without any further problems.  In fact, the
> only time I see this is when running xdb (also on our 835 series).
> Is this a Motif bug? An HP xdb bug? or mine :(?????

     Ummm, more like operator error.  :-) :-) :-)

     Your program is receiving a signal, and, by default, xdb does the
following upon receipt of a signal:

1. It stops the program being debugged.
2. The signal is not ignored (it is passed to the program being
   debugged, as opposed to not being passed).
3. It reports the signal to you.

(Each of the above actions can be individually enabled/disabled.)  In
this case, your program received the SIGCLD signal (death of child -- a
child process terminated).  Xdb detected this fact and then stopped the
program at whatever point the program was in its execution.  It did so
because you did not tell it to do otherwise.

     Continuing your program will not cause any problems, as you
noticed.

     If you do not want your program to be stopped upon receipt of
SIGCLD, you should execute the following command:

	z 18 sr

Here, the number "18" refers to the SIGCLD signal (see, "signal" in
section 5 -- and *NOT* section 2 -- in the man pages for a list of
signal names <--> numbers).  From the man page:

-------------------------------------------------------------------------------
        Signal Control Commands
          The debugger catches all signals bound for the child process
          before the child process sees them.  (This is a function of
          the ptrace(2) mechanism.) For many signals, this is a
          reasonable thing to do.  Most processes are not set up to
          handle segmentation errors, etc.  However, some processes do
          quite a bit with signals and the constant need to continue
          from a signal catch can be tedious.

          z [signal] [i][r][s][Q]
                         Modifies the "zignal" (signal) handling
                         table.  Signal is a valid signal number (the

                         default is the current signal).  The options
                         (which must be all one word) toggle the state
                         of the appropriate flag:  ignore, report, or
                         stop.  If "Q" is present, the new state of
                         the signal is not printed.

          Use the "lz" command to list the current handling of all
          signals.  Note that just "z signal" with no options tells
          you the state of the selected signal.

          For example, assuming a start up state of (do not ignore, do
          not report, do not stop), the command "z 14 sr" sets the
          alarm clock signal to stop (but still do not ignore) and
          report that it occurred.  Doing "z 14 sr" again toggles the
          flags back to the original state.

          When the child process stops or terminates on a signal it is
          always reported, except for the breakpoint signal when the
          breakpoint commands start with "Q".

          When the debugger ignores a signal, the "C" command then
          does not know about it, and the signal will not be passed to
          the child process.  The signal is never ignored when the
          child process terminates, only when it stops.
-------------------------------------------------------------------------------

     -- Darryl Okahata
	UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo
	Internet: darrylo%hpnmd@hp-sde.sde.hp.com

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.