[Top][All Lists]

[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: Sam Halliday
Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Mon, 24 Oct 2016 21:13:33 +0100

I built 96ac0c3 and got a problem with the same part of the build, but
this time at 10%. Apologies, I don't have the free time to do another
debug run on it tonight.

I tried with REL_ALLOC=no and that builds fine! Thank you for the
workaround. I will still try to help with debug info.

Re: docker, it is libre software and you should be able to install it
using whatever package manager you have. It allows you to run
containerised GNU distributions using your current linux kernel.
Pre-built images are made available through the "hocker hub", e.g.

If you have docker installed you would type something like this (don't
forget to add your user to the docker group)

  docker run -it base/archlinux

and (after downloading the "layers"), it will drop you into a shell
running that OS. ArchLinux uses "pacman" as the package manager and
you might need to run something like "pacman -S devel-base emacs" to
get everything you need. Once you exit this shell, all your changes
are lost, so you might want to investigate mounting a local directory
into the container, e.g. so you don't need to download emacs git tree
every time.

I'm no expert, I've only used it a few times before but it is
invaluable when it works.

On 24 October 2016 at 14:29,  <address@hidden> wrote:
> 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 <address@hidden> writes:
>>> From: Noam Postavsky <address@hidden>
>>> Date: Sun, 23 Oct 2016 14:14:59 -0400
>>> Cc: Sam Halliday <address@hidden>, address@hidden
>>> On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <address@hidden> 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]