Xref: utzoo comp.sys.hp:5972 comp.windows.x.motif:493 Path: utzoo!attcan!uunet!kddlab!titcca!kogwy!new1!roger From: roger@zuken.co.jp (Roger Meunier) Newsgroups: comp.sys.hp,comp.windows.x.motif Subject: Re: fork()/exit() dumps core Message-ID: Date: 20 Aug 90 16:42:12 GMT References: <5768@hplabsz.HPL.HP.COM> Sender: news@new1.zuken.co.jp Followup-To: comp.sys.hp Organization: ZUKEN Inc. Yokohama, JAPAN Lines: 55 In-reply-to: mayer@hplabsz.HPL.HP.COM's message of 9 Aug 90 20:35:59 GMT In article <5768@hplabsz.HPL.HP.COM> mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes: >I don't think this has much to do with HP's implementation, nor C++ -- it >is a general problem you have to watch out for when doing system(), popen() >and fork() under X. > >Basically, your application's open connections to the X server take up file >descriptors, and these are all faithfully copied upon vfork()/fork().... > >To fix the problem, you need to close the file descriptors after you >fork, ^^^ I am not the one who is fork()'ing; Motif is. My destructors get called when the kanji input server (/usr/lib/nlio/serv/X11/xj0input) is spawned, because exit() (rather than _exit()?) is being called in the child environment. My destructor calls XCloseDisplay(), at which time some error occurs, and core is dumped because the error message cannot be output. Here's a sample stack trace of the core dump: 0 __doprnt + 0x6 1 __fprintf + 0x32 2 __XIOError + 0x30 3 __XReply + 0x20 4 _XSync + 0x52 5 _XCloseDisplay + 0x64 ... 10 _STDmain_cxx_ () 11 _exit + 0x38 12 __XIOError + 0x80 13 __XReply + 0x20 14 _XSync + 0x52 15 _XCloseDisplay + 0x64 ... 49003 _STDmain_cxx_ + 0x10 49004 _exit + 0x38 49005 _XHPInputChinese_t + 0x652 49006 _XHPNlioctl + 0xac 49007 _XmTextInputCreate + 0x218 49008 _XmTextSetHighlight + 0x2f6 49009 __XtAddDefaultConverters + 0x520 49010 __XtCreate + 0x1da 49011 _XtCreateWidget + 0xac 49012 _XmCreateText + 0x1c ... In this case, the error during XCloseDisplay() causes a call to exit(), which calls the destructors *again*, ad infinitum. This doesn't occur every time; usually _XIOError() bombs at the first _doprnt() and never gets to call exit(). This raises another question: if static destructors can trigger an error condition which in turn triggers a call to exit(), is there some standard method for avoiding the above infinite looping? -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)