Xref: utzoo comp.sys.hp:5875 comp.windows.x.motif:395
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!hplabs!hplabsz!mayer
From: mayer@hplabsz.HPL.HP.COM (Niels Mayer)
Newsgroups: comp.sys.hp,comp.windows.x.motif
Subject: Re: fork()/exit() dumps core
Message-ID: <5768@hplabsz.HPL.HP.COM>
Date: 9 Aug 90 20:35:59 GMT
References: <ROGER.90Aug9114200@rd11.zuken.co.jp>
Reply-To: mayer@hplabs.hp.com (Niels Mayer)
Organization: Hewlett-Packard Labs, Software & Systems Lab, Palo Alto, CA.
Lines: 57
Summary:
Expires:
Sender:
Followup-To:

In article <ROGER.90Aug9114200@rd11.zuken.co.jp> roger@zuken.co.jp (Roger Meunier) writes:
>When a C++ program exits, it calls a list of destructors to clean up
>static data.  But what happens when exit() is called after fork()?
>
>I ran into a problem with HP's implementation of Motif 1.0.  For the
>XmText widget, they allow Chinese character input by setting up a
>connection with an input server.  Apparently, they fork() the server
>on the first XmCreateText().  I noticed that in one of my applications,
>it was taking an extremely long time to create the first text widget
>(8+ sec.), and that core was being dumped during the creation.  Looking
>at the core file with cdb, I noticed that exit() was being called from
>the routine that did the fork(), and that subsequently all my static
>destructors were being called, including one that caused the core to
>be dumped (it was calling XCloseDisplay()!).  Why the *child* process
>should be trying to do this is beyond me.
>
>Has anyone else run into similar problems when fork()'ing in a C++
>environment?  Is this a design problem with the C++ static object clean-up
>strategy, or is HP's implementation of nlio forgetting to take C++ into
>account, or both?

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, e.g.:
  pid_t pid;
  if((pid = vfork()) == 0)
  {
    for(i=3;i<_NFILE;i++)  /* close all fd except stdin, stdout, and stderr */
        close(i);
    ...
   }

As to why the X implementation doesn't set the close-on-exec flag via
fcntl() to prevent this problem, only the experts know.

			--------------------

I'm trying to deal with a similar problem right now as a matter of fact.

Does anybody have a public domain (or non-restrictive-copyright) version of
popen() and system() that you'd be interested in sharing???

Actually, system() is easy... But I'm too lazy to go figure out how to do
popen() without sullying the pristine "clean-room" environment of my mind.

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *