Re: address@hidden: 21.1 on Solaris 2.5.1 (sparc), on terminal, core dump]

[Paul Eggert]

> Date: Wed, 5 Dec 2001 02:48:05 -0700 (MST)
> From: Richard Stallman <address@hidden>
> 
>     The problem is not limited to Solaris 2.5 and later: it will
>     also occur on earlier Solaris versions, and I think it'll occur
>     on other hosts as well.  The more general problem is that Emacs
>     sometimes uses vfork without defining HAVE_VFORK.
> 
> That itself seems like an anomaly.  How does it come about that Emacs
> uses vfork when HAVE_VFORK is not defined?

I think it happened this way:

- Emacs used to rely on its own configuration files for deciding about vfork.
- It's now relying on Autoconf, mostly.
- The vfork conversion to Autoconf wasn't done completely.
- Emacs's internal vfork configuration files sometimes disagree with Autoconf.
- When they disasgree, Emacs can dump core.

If you like, I can propose patches that solve the problem more
generally than just putting in a #define for Solaris.  (I'm pretty
sure the problem isn't limited to Solaris.)  I'll need to supply
patches for the main trunk that differ from the patches on the Emacs
21 branch, since the Autoconf versions have changed.


> Does Emacs use vfork directly,
> or does it call library subroutines that use it?

Certainly the former.  Most probably the latter, too, as some Solaris
library routines (e.g. "system") invoke vfork.

The current core dump is because of the former.


> I wonder why HAVE_VFORK wasn't defined on older Solaris versions.
> They have all had vfork.  Was it broken?

Yes, but that was long ago.  Emacs had porting problems with early
Solaris versions, and vfork was turned off for a while on those hosts.
But vfork was reenabled later once the Emacs code was altered so that
it did port to those hosts.  Please see my 1995-12-12 ChangeLog entry
for more.


>     One way to fix the more general problem would be to use the
>     AC_FUNC_FORK of Autoconf 2.51 and later.  It defines a macro
>     HAVE_WORKING_VFORK that Emacs could use instead of HAVE_VFORK.
> 
> Does HAVE_WORKING_VFORK operate by executing a test program?

Yes.


> It is desirable to avoid that kind of Autoconf test, because it does
> not work in cross-compilation.

In cross-compilation, Autoconf guesses based on the host type.  For
example, it knows that AmigaOS and DJGPP have only a dummy fork that
doesn't really work.  Right now, for vfork Autoconf guesses based on
whether vfork compiles and links properly, but this guess can be
improved to be as accurate as Emacs's guesses, if that's still needed.

I think that the vfork porting problems requiring manual intervention
are all for systems that nobody uses any more.  If I'm right, the
current Autoconf guesses are good enough; if not, we can easily fix
Autoconf.