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

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

Re: c-mode imenu: Stack overflow in regexp matcher


From: Stefan Monnier
Subject: Re: c-mode imenu: Stack overflow in regexp matcher
Date: Sun, 04 Feb 2007 20:18:00 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux)

> I've reduced the problem to a regexp search called from:

> (imenu--generic-function imenu-generic-expression)

> Evaluating the following in a buffer visiting splash.xpm as text
> causes a stack overflow in the regexp matcher:

>   (goto-char (point-max))
>   (re-search-backward 
> "^\\<[^()]*[^[:alnum:]_:<>~]\\([[:alpha:]_][[:alnum:]_:<>~]*\\)\\([     
> \n]\\|\\\\\n\\)*(\\([   \n]\\|\\\\\n\\)*\\([^   \n(*][^)]*\\)?)\\([     
> \n]\\|\\\\\n\\)*[^      \n;(]" nil t ))


> A 32-bit version works fine on x86_64, but the 64-bit version has the
> problem.

Probably the stack space is just sufficiently different for it to work in
one case and not in the other.  If you change the stacksize limit, you'll
probably be able to make it fail/succeed in either case.

Please try and play with the text being matched to try and see which part of
the regexp is causing an overflow.  Most likely the problem is that
something is matching a much longer text than expected (e.g. tens/hundreds
of nonempty lines rather than 1 or 2).

Maybe it's the beginning: "^\\<[^()]*" since the \< only implies that the first
char will be a word-constituent, and the [^()]* can then match any number of
chars as long as there's no intervening parenthesis, which seems quite
possible in a long comment.


        Stefan




reply via email to

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