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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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