> 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
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
