>>>> Jan Vroonhof writes:
Jan> I am reading this remote so I cannot check all the details.
Ok, I fill you in.
Jan> Andreas Jaeger <aj(a)suse.de> writes:
> Btw. just run `nm xemacs |grep malloc_hook' on the binary
after applying
> my other patch - we really don't need malloc_hook if DOUG_LEA_MALLOC
> is used.
Jan> Is there a documented guarantee this will never be needed? I'll happy
Jan> to take your word for glibc related things, but isn't it is possible
Jan> that for instance the gcc folk could decide to set it in libgcc.a? Or
Jan> should I take your comment to mean that glic's malloc doesn't use the
Jan> hook at all?
If we compile with DOUG_LEA_MALLOC, XEmacs nowhere sets or uses
__malloc_hook - besides in this one place. __malloc_hook is essential
for GNU malloc - but with Doug Lea's malloc, we don't need it.
glibc needs to initialize its malloc implementation and uses
__malloc_hook for this initilisation. If you set __malloc_hook to
NULL, the initialisation code is not executed at all - and the malloc
implementation will fail. Therefore, we've got two solutions for
XEmacs for now:
- call malloc before setting __malloc_hook so that it gets initialised
(my first patch)
- don't set __malloc_hook at all.
Since __malloc_hook is part of glibc and not part of gcc, we only have
to deal with glibc here.
Jan> Is the version in Debian potato an official released version. If not
Jan> would it may be better just to make this patch when there is actually
Jan> a version with this problem released?
The version 2.1.2-6 from Debian is based on the current CVS version of
glibc 2.1.3 - nothing official.
BUT: All distributions[1] use at least some patches from the CVS
archive. I don't think there's a distribution that uses plain 2.1.2
without patches. I guess that users of the current Debian potato, the
latest RedHat release (6.1?) and of the coming SuSE release (6.3) who
try to compile their own XEmacs, get these problems.
Jan> Jan
Jan> P.S. I am interpreting your patch correctly as saying glibc doesn't
Jan> actually define malloc_hook until after the first malloc.
Yes - and this is a bug IMO. glibc uses __malloc_hook internally -
and also externally.
After malloc is initialized, __malloc_hook can be used by user
programs - but before malloc is initialized you've got to be careful.
This is broken. But there's no trivial patch for glibc.
Andreas
Footnotes:
[1] Ok, I know only SuSE, RedHat and Debian in this regard.
--
Andreas Jaeger
SuSE Labs aj(a)suse.de
private aj(a)arthur.rhein-neckar.de