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

[Stefan Monnier]

> 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.  Here's how search.c calls re_search_2:

>       p1 = BEGV_ADDR;
>       s1 = GPT_BYTE - BEGV_BYTE;
>       p2 = GAP_END_ADDR;
>       s2 = ZV_BYTE - GPT_BYTE;
>       if (s1 < 0)
>       {
>         p2 = p1;
>         s2 = ZV_BYTE - BEGV_BYTE;
>         s1 = 0;
>       }
>       if (s2 < 0)
>       {
>         s1 = ZV_BYTE - BEGV_BYTE;
>         s2 = 0;
>       }
>       re_match_object = Qnil;

>       while (n < 0)
>       {
>         EMACS_INT val;
>         val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2,
>                            pos_byte - BEGV_BYTE, lim_byte - pos_byte,
>                            (NILP (Vinhibit_changing_match_data)
>                             ? &search_regs : &search_regs_1),
>                            /* Don't allow match past current point */
>                            pos_byte - BEGV_BYTE);

> We pass s1 and s2, which are pointers to buffer text, so if buffer
> text is relocated, we are screwed.

> Does this explanation sound reasonable?  If so, any ideas how to fix
> this?

I suggest you let-bind some witness variable is re_search_2 and then in
the buffer-relocation code, you test this var and abort if it's non-nil.
That should let us catch the offender red-handed, after which we will
know better how to fix the problem.


        Stefan