Re: more on the emacs-20.3 segfault

[Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>]

Hello,

> Further suggestions gladly accepted.  I have no clue whether 
> this is more likely emacs's or glibc's problem (or even the 
> kernel: Peter and I are running 2.2 while Wolfram has 2.0).  

Ah, the joys of the emacs dumping procedure !  Here's what I think
happens:

1 Emacs dumped executable starts up, loads ld-linux.so.2/libc.so.6

2 The dynamic loader of glibc invokes atexit(), which uses malloc()
  (this is new in glibc-2.1.1, I think; previous versions didn't
   use malloc so early)

3 malloc hands out chunk outside the `dumped' heap (just as if
  emacs was an ordinary executable)

4 Only now main() is executed and emacs calls malloc_set_state()

5 malloc()s from now on are happening in the dumped heap

6 At exit() time, the chunk allocated in step 3 is freed, which
  is outside the heap

7 Boom!

How to fix ?  I don't think there is a way to have an ELF executable
call a libc symbol (malloc_set_state()) before the dynamic linker is
inititalized, correct ?

So I think that Emacs should install a hook for malloc() (it already
does so anyway, AFAIK) and call malloc_set_state() from that hook when
malloc() is called for the first time, rather than from main().  If I
don't receive better suggestions, I'll try to implement that, but it
may take a few days.

Anyway, I'm now pretty sure this is Emacs' problem and not a glibc
problem.  The `dumped' executable is simply very hard to get right
with dynamic linking.

Regards,
Wolfram.
-- 
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de