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.