GNU bug report logs -
#11519
"Wrong type argument: characterp" building custom-deps while boostrapping
Previous Next
Reported by: Juanma Barranquero <lekktu <at> gmail.com>
Date: Sat, 19 May 2012 16:12:02 UTC
Severity: normal
Found in version 24.1.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Note that the address of buffer text has changed from 0x10757948 to
> 0x10826948. And the culprit is ...
> #7 0x010397fb in xmalloc (size=786436) at alloc.c:727
> #8 0x0120da2d in load_charset_map_from_file (charset=0x1944970,
> mapfile=57455953, control_flag=1) at charset.c:501
Huh! Indeed, I always assumed that relocation would be something that
can only happen during GC, not in a mere xmalloc.
> The marked line calls string_char, which calls maybe_unify_char, which
> calls load_charset, which causes memory allocation and relocation of
> buffer text.
This brings up back to the issue of calling maybe_unify_char in
STRING_CHAR_AND_LENGTH. One more strike against it. Handa, could you
prepare a patch that removes this?
> If you agree with the diagnosis, then how about the change below?
Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd
replace "inhibit ? 0 : 1" with "!inhibit"). But is it really new in
Emacs-24? It seems the same problem is already present in Emacs-23, so
it's probably not so urgent to fix it for 24.1.
> It fixes the problem for me. (Or is there a better way?) If accepted, I
> will add the necessary commentary to this code and a prototype for the
> new function. In any case, I suggest to install the fix on the
> emacs-24 branch, because this issue is a disaster waiting to happen.
I wonder: why do we use REL_ALLOC?
Stefan
This bug report was last modified 11 years and 229 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.