Red Hat Bugzilla – Bug 107402
Stack overflow in regexp matcher
Last modified: 2007-11-30 17:10:32 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I compile a C program inside Xemacs. I see errors. I hit C-x ` (next-error) to jump to the next error. Xemacs says: Stack overflow in regexp matcher I (setq debug-on-error t) and hit C-x ` again to get a stack backtrace, which I won't paste here because it seems too large for Bugzilla to handle. Version-Release number of selected component (if applicable): xemacs-21.4.14-1 How reproducible: Always Steps to Reproduce: 1.M-x compile Make sure to use a large file with a lot of errors. E.g.,sshconnect2.c in the openssh tree. A trivial file will not have this problem. 2.C-x ` Actual Results: Stack overflow in regexp matcher Expected Results: Xemacs should move the next error to the top of one buffer and show the source code near that error in another buffer. Additional info: I recompiled the package with this diff, but the spec file does not seem to be buildable in an empty BUILD tree. One problem was that this line was needed: mkdir -p /tmp/rpmbuild/xemacs-21.4.14-root/usr/local/X11R6/lib/X11/ja/app-defaults/Emacs another problem was that the built xemacs binary did not seem to be able to load any files. I believe the problem is in the .spec file, because I reverted my changes, did another rpmbuild, and was left with a similarly broken xemacs binary. If you can tell me how to make the rpmbuild work, I can test this patch. --- xemacs-21.4.14/src/regex.c.rik 2003-06-18 23:34:42.000000000 -0400 +++ xemacs-21.4.14/src/regex.c 2003-10-17 14:38:48.000000000 -0400 @@ -1140,7 +1140,7 @@ static const char *re_error_msgid[] = whose default stack limit is 2mb. */ int re_max_failures = 20000; #else -int re_max_failures = 2000; +int re_max_failures = 20000; #endif union fail_stack_elt I tried that patch because of this posting: http://list-archive.xemacs.org/xemacs-beta/200204/msg00120.html
Here is a more recent bug report and patch: http://list-archive.xemacs.org/xemacs-beta/200309/msg00205.html
Thanks for the report. Applying the above patch in xemacs-21.4.13-3.
21.4.14-3 even
As for the build problems you are having 21.4.14-2 and later no longer need %_prefix/X11R6/lib/X11/ so that problem should be gone. So the built xemacs can't find any elisp files? I think you need xemacs-sumo installed.
I have tested -3, and it C-x ` works for a much larger range of programs. However, I still see a stack overflow at times. I have added the following lines to the xemacs.spec file after the %patch20 line and this seems to help: cp -p src/regex.c src/regex.c.rik sed 's,int re_max_failures = 20000;,int re_max_failures = 40000;,' \ < src/regex.c.rik > src/regex.c However, I haven't seen any postings suggesting this will be an upstream fix. [Also, the build problems seem to be resolved ASSUMING I build xemacs-sumo.spec before xemacs-spec, and they have version numbers that match. I believe this is expected behavior.]
Using 40000, 4000 in xemacs-21.4.14-4.
[Not sure what you mean by "version numbers that match"?]
Sorry for not being clear. If I build and install xemacs.spec and xemacs-sumo.spec simultaneously, xemacs will only be able to find its startup files if the Version AND Release lines are identical in the two *.spec files. (This is a change from pre-RH9, for example, where I was able to bump just the Release on the xemacs.spec file and have it work with whatever other xemacs packages were installed.)>
I'm probably overlooking something obvious, but how can the version numbers of xemacs and xemacs-sumo be the same?
Sorry, I misspoke. I thought that the Release (not Version) numbers had to be the same. But that's wrong too. Please ignore comment #8. The problem was that the hardcoded paths in sitestart.el assumed a full installation in /usr, and I was building xemacs to install in /usr/local. I have corrected this problem and can now build a one-off xemacs package that relies on the standard Fedora xemacs-sumo package.