[comp.sys.hp] Motif and xdb problem

john@quonset.cfht.hawaii.edu (John Kerr) (09/20/90)

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 :(?????

Mahalo


 ----------------------------------------------------------------------------
 John Kerr                      Canada-France-Hawaii Telescope Corp.
                                INTERNET: john@cfht.hawaii.edu 
                                BITNET:   john@uhcfht
 ----------------------------------------------------------------------------

evgabb@sdrc.UUCP (Rob Gabbard) (09/20/90)

From article <9474@uhccux.uhcc.Hawaii.Edu>, by john@quonset.cfht.hawaii.edu (John Kerr):
> 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)

Try executing this command in xdb or put it in the file $HOME/.xdbrc:

	z 18 s

This tells xdb not to stop when it receives a death of child signal (signo 18).
The signal still gets passed to the process you are debugging.  If it still 
gives a message when this occurs but doesn't stop and you want to get rid of the
message, you can make the command above:

	z 18 sr

which toggles off reporting for that signal.  Enter lz to list the current state
of all signals, or just z <signo> to get the status of a particular signal.

-- 

Rob Gabbard (uunet!sdrc!evgabb)  
Technical Development Engineer   
Structural Dynamics Research Corp

bruno@hpfcso.HP.COM (Bruno Melli) (09/20/90)

>   death of child (no ignore) at 0xa1ff0
>   (file unknown): _sigprocmask +0x8: (line unknown)

If you do a stack trace at this point, you most likely get something
like this:

 0 _sigprocmask + 0x8 (0xffeff1d4, 0x400, 0x1430, 0xffeff1d4, 0x400)
 1 _getcwd + 0x16 (0xeae6c, 0x1, 0x1a8, 0xffefda04, 0xd6888)
                        [ more stuff here ]
 7 _XmCreateFileSelectionDialog + 0x52 (0xd0edc, 0x98011, 0, 0, 0xd21b8)
 8 main (argc = 1, argv = 0xffeffb44)    [t.c: 34]

getcwd(3C) does a fork(). The death of child signal you get is when the
child process of the fork() exits. Xdb gets notified because the
child process of the fork() is in the same group ID.

So that doesn't mean there is anything wrong with your program. Continuing
the program as you are doing is the right thing to do.

bruno.

darrylo@hpnmdla.HP.COM (Darryl Okahata) (09/20/90)

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.

tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (09/21/90)

>>   death of child (no ignore) at 0xa1ff0
>>   (file unknown): _sigprocmask +0x8: (line unknown)
 
> So that doesn't mean there is anything wrong with your program. Continuing
> the program as you are doing is the right thing to do.

Notice the part  "death of child (NO IGNORE)"  If you wish, you can tell
xdb to ignore certain situations.  Example invocation:

     % xdb foo -p xdb.script

where xdb.script contains:

    z 18 irs

Starting xdb, you'll see

     Copyright Hewlett-Packard Co. 1985.  All Rights Reserved.
     <<<< XDB Version A.07.05 HP-UX >>>>
     Playing back from "xdb.script"

     z 18 irs
     Sig  Stop    Ignore  Report  Name
      18  No      Yes     No      death of child

     End of playback

For certain debugging sessions, its handy to ignore lots of things.

Thomas Gilg
tomg@cv.hp.com

phil@hpsmdca.HP.COM (Philip Walden) (09/21/90)

I believe xdb "hooks" into all the process'es signals. If some low level
routine executes another process and that process terminates, the sigchild
signal is reported by xdb. If you don't like it, you can tell xdb to ignore
it with the z command. Read the xdb man section on Signal Control Commands.

john@quonset.cfht.hawaii.edu (John Kerr) (09/22/90)

Thanks to all that responded, but only one person responded
correctly.   The problem I was looking to resolve did not
have anything to do with running xdb (in other words, not operator
error).  I know about signals and the effects on debuggers.  What
was puzzling was that I was NOT forking any children.  My question really
was -- If I did not fork some process, then WHO DID?

The culprit lies hidden in XmFileSelectionBox.  Upon examining the trace
of execution, I see that getcwd() is invoked by XmFileSelectionBox...
This is the nasty little guy that forks off a process.  In fact there
is no mention of signals in getcwd(3C).  Seems to me that this could
be a really bad snare in certain applications.  Why does getcwd
need to do this?  Is it execing a shell to do a 'pwd'????

Anyway, 'nuff already.  The side effects are minimal, the sun still
rises in the east, so, to heck with it and back to work.


 ----------------------------------------------------------------------------
 John Kerr                      Canada-France-Hawaii Telescope Corp.
                                INTERNET: john@cfht.hawaii.edu 
                                BITNET:   john@uhcfht
 ----------------------------------------------------------------------------

tbc@hp-lsd.COS.HP.COM (Tim Chambers) (09/22/90)

[ explanation deleted ]
> So that doesn't mean there is anything wrong with your program. Continuing
> the program as you are doing is the right thing to do.

> bruno.

I frequently run into this.  I've gotten used to entering the xdb command
"z 18 s" to tell xdb not to stop for it.