Re: Dumper problems and a possible solutions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Jun 2014 16:34:03 -0400
> From: Rich Felker <dalias@libc.org>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> 
> > And still, there are only a few (maybe 10) times we allocate these
> > 700K tables, so 400MB sound very strange to me.
> 
> In my log, I see 768k allocations occuring roughly 94 times.

768K times 94 doesn't get anywhere close to 400MB.

> Is it possible that the temacs --batch commands I'm testing (IIRC
> taken from commands that were failing in leim/Makefile, but perhaps
> I changed it in some way I didn't notice?) are pulling in my .emacs
> file, which might be causing more charsets to be loaded?

No, it's more probable that I was mistaken about the count.  But
still, 400MB sounds way too much.

> > > > Sorry, I don't see the difficulty.  Just make malloc/realloc/free be
> > > > pointers that point to gmalloc's implementation before dumping, and to
> > > > the libc implementation after it.  You may need some #define to rename
> > > > malloc to some other symbol, to avoid name clashes.  Am I missing
> > > > something?
> > > 
> > > Yeah, what happens if, after dumping, the real emacs at runtime ends
> > > up calling free() on one of the pre-dump pointers?
> > 
> > You intercept the call and do nothing.
> 
> Right, but the free pointer can't directly point to the real (libc)
> free. It has to point to the wrapper that does this range-check.

Right.

> > > Those ctors are free to inspect global data. For example one might
> > > contain (this sort of idiom is necessary if you can't control the
> > > relative order of ctors): if (!init) { do_something(); init=1; }. In
> > > that case, the dump would save the value of init, and do_something()
> > > would fail to happen at runtime.
> > 
> > That's the same problem as with your clock_gettime, and it must be
> > fixed anyway, because any ctor run at dump time is almost certainly
> > picking up data that is irrelevant to the run time.
> 
> Libc could _possibly_ work around it by virtue of having full control
> over the init code. For other libraries, the issue is not fixable (see
> my above example with code that has to control dependency order of
> ctors), and shouldn't have to be fixed.

But the problem likely doesn't exist, because otherwise we will have
known about it by now.  Emacs cannot use such libraries.