GNU bug report logs - #11519
"Wrong type argument: characterp" building custom-deps while boostrapping

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: lekktu <at> gmail.com, schwab <at> linux-m68k.org, 11519 <at> debbugs.gnu.org
Subject: bug#11519: "Wrong type argument: characterp" building custom-deps	while boostrapping
Date: Tue, 22 May 2012 22:02:09 +0300

> From: Kenichi Handa <handa <at> gnu.org>
> Cc: schwab <at> linux-m68k.org, lekktu <at> gmail.com, 11519 <at> debbugs.gnu.org
> Date: Tue, 22 May 2012 23:38:34 +0900
> 
> In article <83vcjpxw18.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So I think that what happened is that something, probably the
> > translation through a char-table, caused allocation of a large chunk
> > of memory, which in turn relocated the text of the current buffer
> > behind regex.c's back, which still uses C pointers to the old location
> > of the buffer text.
> 
> The function char_table_translate may allocate some amount
> of memory.  But that's only when the char-table is one of a
> "unicode character property table" loaded via the function
> uniprop_table.  When char_table_translate is called from
> re_search_2 (via the macro RE_TRANSLATE), the char-table to
> lookup is one of a case-related table (equiv? canon?) which
> is not a unicode property table.

You are right: it was not char_table_translate, it was
load_charset_map_from_file, invoked through STRING_CHAR_AND_LENGTH.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.