bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24358: 25.1.50; re-search-forward errors with "Variable binding dept


From: npostavs
Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Mon, 24 Oct 2016 09:29:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

I was able to reproduce the failure in ja-dic-cnv after removing
--with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no
--with-jpeg=no from my configure args (I guess using GTK changes the
allocation patterns), and doing 'make extraclean'.

The error went away after I updated to the latest emacs-25 commit:
ee04aedc72 "Fix handling of buffer relocation in regex.c functions".
The error occurs in the commit just before it 71ca4f6a "Avoid relocating
buffers while libxml2 reads its text", so I think Eli's fix for the base
pointer in search_buffer does solve the problem.

Sam, can you confirm if this fixes it for you?

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sun, 23 Oct 2016 14:14:59 -0400
>> Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org
>> 
>> On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > Noam, I think we need these two changes, because otherwise looping
>> > more than once in search_buffer will fail to update the pointers
>> > passed to re_search_2, if buffer text was relocated inside
>> > re_search_2.
>> >
>> > Do you agree?
>> 
>> Ack, yes! Missing the update to base was a total thinko on my part.
>
> Pushed.
>
> There might be a more serious problem with this, unfortunately: the
> search registers are computed in regex.c using pointers into the C
> strings that are being searched.  The general paradigm is as in this
> fragment:
>
>   regstart[*p] = d;
>   [...]
>   regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]);
>
> POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is
> consistent with the current base address of the string into which it
> points.  Did you study this aspect of regex.c when you decided which
> values need to be affected by relocation?

I did not look at that before, but looking now, I don't see why it would
be a problem.  I put the base address updating code around the only
place where malloc may be called, so string1 and string2 (which
POINTER_TO_OFFSET uses) should always be consistent with the base
address (unless there is some other malloc call that I missed?).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]