Bug#762438: libgtk-3-0: makes emacs crash (Segmentation fault) when called from a git or svn directory

[Simon McVittie]

On 22/09/14 13:34, Vincent Lefevre wrote:
> Because in both cases the crash occurs in __GI_getenv from getenv.c,
> I suspect that the problem with the new libgtk-3-0 is related to this
> known bug, and just makes it occur much more often.

I don't think this is a grave ("renders package unusable") bug in Gtk;
Gtk is working fine in other applications that don't do the odd things
with environ that emacs does. If you consider it to be RC for emacs,
maybe it is. I think it should be fixed in emacs.

What emacs appears to be doing is:

* vfork() in thread A
  - parent: thread A suspended
  - parent: threads B, C, ... (one of which is the Gtk GUI) continue
  - child: "shares all memory with its parent, including the stack"
    per vfork(2)

* child copies environ and modifies the copy as needed

RACE:
child + parent thread A:
  * changes the global environ pointer, potentially making it point to
    a new mmap() that only exists in the child process (or something?)
  * child: calls execvp()
  * parent: thread A resumes and puts the old environ back
parent threads B, C...
  * threads B, C, ... continue their work and might call getenv()

If the child wins the race, everything's OK; if the parent's threads B,
C... "win" the race, everything explodes. It seems that Gtk, in the
parent's GUI thread, is now more likely to "win" the race and crash,
because new features like touchscreen support have the side-effect that
it calls getenv() more often.

On the upstream emacs bug, Troels Nielsen wrote:
> In the meantime, retaining support for vfork would be nice, because
> on some platforms, like Cygwin, fork is still very slow

but on Linux (and hopefully also *BSD and Hurd), fork() is quite fast,
and considerably less crashy. I would suggest changing the vfork() call
to fork(), making sure the environ rewriting is only done in the child
side of the fork(), and seeing whether that helps.

Alternatively, emacs could use execvpe() instead of execve() on
platforms where it exists (including all GNU platforms as far as I
know), so that it does not need to alter the value of environ at all on
such platforms. I think that would fix this?

    S