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

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

RE: re-search-forward ... nil t) results in error instead of returning n


From: Drew Adams
Subject: RE: re-search-forward ... nil t) results in error instead of returning nil
Date: Sat, 20 Nov 2004 17:30:00 -0800

I don't claim to know how the implementation works, but for info: I tested
the same search in the same virgin 21.3.50 Emacs 21 (emacs -q each time),
and sometimes I got the stack overflow and sometimes (rarely) I did not. As
I said earlier, the successful matches, without overflow, sometimes happened
the first thing after opening Emacs, and sometimes they happened after
having already gotten the stack overflow a few times.

The test I used always looked for the same command (abbrev-mode) at the same
Info node (Key Index) - try Info-goto-emacs-command-node abbrev-mode to
see - so TEXT and N should be the same each time. STACK is apparently the
only variable here.

The fact that it works systematically in Emacs 20 might be due to the change
between versions that you postulate. I don't understand why it works
sometimes in Emacs 21 and sometimes not, however.

Have you tried this in CVS Emacs (I have a slightly older version)? Do you
get the same behavior as I?

Thanks,

  Drew


    > (re-search-forward
    "\"\\(?:[^\\\"]\\|\\\\\\(?:.\\|[\n]\\)\\)*\"\\|`[^']+'"
    [...]
    > Debugger entered--Lisp error: (error "Stack overflow in
    regexp matcher")
    [...]
    > BTW (probably unrelated to bug): In Emacs 20, doing the same thing,
    > but using this similar regexp (no non-greedy matching), succeeds, with
    > no Stack overflow error:
    > "\"\\([^\\\"]\\|\\\\\\(.\\|[\n]\\)\\)*\"\\|`[^']+'"

    The stack-overflow error depends on the text being matched.  In
    the present
    case, the condition for this error is basically that TEXT/N >
    STACK where
    TEXT is the number of chars in the buffer (after point), STACK
    is the amount
    of stack space left when the function is called, and N is a
    constant that
    depends on how the regex.c code is compiled (i.e. things like
    size of `int'
    and pointers).  N has changed between Emacs-20 and Emacs-21, so
    maybe that's
    the source of the problem (I can't remember if N got smaller or bigger,
    tho), but a more likely situation is that TEXT was not the same in your
    two tests.





reply via email to

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