[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dumper problems and a possible solutions
From: |
Eli Zaretskii |
Subject: |
Re: Dumper problems and a possible solutions |
Date: |
Thu, 26 Jun 2014 05:44:44 +0300 |
> Date: Wed, 25 Jun 2014 16:34:03 -0400
> From: Rich Felker <address@hidden>
> Cc: address@hidden, address@hidden
>
> > 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.
- Re: Dumper problems and a possible solutions, (continued)
- Re: Dumper problems and a possible solutions, Dmitry Antipov, 2014/06/25
- Re: Dumper problems and a possible solutions, Eli Zaretskii, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Eli Zaretskii, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Eli Zaretskii, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Eli Zaretskii, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions,
Eli Zaretskii <=
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/26
- Re: Dumper problems and a possible solutions, Eli Zaretskii, 2014/06/26
- Re: Dumper problems and a possible solutions, Stefan Monnier, 2014/06/25
- Re: Dumper problems and a possible solutions, Stefan Monnier, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Stefan Monnier, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Paul Eggert, 2014/06/25
- Re: Dumper problems and a possible solutions, Rich Felker, 2014/06/25
- Re: Dumper problems and a possible solutions, Stefan Monnier, 2014/06/25