Re: Emacs 23.1.93 pretest

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Cc: address@hidden
> Date: Sat, 27 Feb 2010 16:37:47 -0500
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > "bzr bisect" points to this change as the reason for this bug:
> >
> >     2010-02-05  Chong Yidong  <address@hidden>
> >
> >         * charset.c (load_charset_map_from_file): Allocate large
> >         charset_map_entries structure on the heap rather than the stack.
> >         (Bug#5526).
> >
> > The revisions before this change works correctly; all revisions after
> > it fail as described above.
> 
> Hmm, this is strange.  This change (actually the succeeding 2010-02-06
> change to the same place) switches from using alloca to SAFE_ALLOCA
> (i.e. malloc, since the desired structure is large).  But the only way I
> can see for this code to crash is if load_charset_map somehow makes a
> pointer into the allocated structure.  But in that case, the old alloca
> case should have crashed too.

Yes, it _is_ weird.  But the effect (see below) does look like we are
freeing memory being used, or maybe overwriting some allocated buffer,
or in some other way thrashing the arena.

> If you remove the SAFE_FREE () calls, does that prevent the crash?

There's only one SAFE_FREE call that I see; if I remove it, temacs
crashes at loadup time, when it loads mule-conf.  So I cannot even get
as far as building Emacs.

Btw, the problem I was trying to reproduce with "bzr bisect" was not a
crash, but rather the fact that visiting an emacs-mule encoded desktop
file with that Latin-2 character in it caused some 15K characters
following the Latin-2 one be overwritten with nulls.  The original
crash somehow happens only when I click on an icon that invokes
runemacs.exe, and I cannot reproduce it with the -Q switch.  But since
both issues seem to be related to decoding emacs-mule, and they both
happen when visiting or loading the .emacs.desktop file, I'm assuming
that these are different manifestations of the same problem.