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

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

Re: Stack overflow in regexp matcher when opening file


From: Kim F. Storm
Subject: Re: Stack overflow in regexp matcher when opening file
Date: Fri, 03 Feb 2006 15:56:56 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Kim F. Storm" <address@hidden> writes:

> Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
>   looking-at("\\(?:<\\?xml\\s +[^>]*>\\)?\\s 
> *<\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\(?:!DOCTYPE\\s +[^>]*>\\s *<\\s 
> *\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\)?[Hh][Tt][Mm][Ll]")
>   #[(re dummy) "�!‡" [re looking-at] 2]("\\(?:<\\?xml\\s +[^>]*>\\)?\\s 
> *<\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\(?:!DOCTYPE\\s +[^>]*>\\s *<\\s 
> *\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\)?[Hh][Tt][Mm][Ll]" nil)
>   assoc-default(nil (("\\(?:<\\?xml\\s +[^>]*>\\)?\\s 
> *<\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\(?:!DOCTYPE\\s +[^>]*>\\s *<\\s 
> *\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s *<\\)*\\)?[Hh][Tt][Mm][Ll]" . html-mode) 
> ("<\\?xml " . xml-mode) ("\\s *<\\(?:!--\\(?:[^-]\\|-[^-]\\)*-->\\s 
> *<\\)*!DOCTYPE " . sgml-mode) ("%![^V]" . ps-mode) ("# xmcd " . 
> conf-unix-mode)) #[(re dummy) "�!‡" [re looking-at] 2])
>   set-auto-mode()
>   normal-mode(t)
>   after-find-file(nil t)
>   find-file-noselect-1(#<buffer file2.txt> "~/fsf/latest/file2.txt" nil nil 
> "~/fsf/latest/file2.txt" (2320055 774))
>   find-file-noselect("~/fsf/latest/file2.txt" nil nil t)
>   find-file("~/fsf/latest/file2.txt" t)
>   call-interactively(find-file)

The following patch limits the scope of magic-mode-alist regexp
matches at the beginning of the file to the first 4K of the file.

This fixes this problem for me, but it doesn't explain why the problem
happens in the first place.  I don't know if this is the proper
approach, but it does seem to make sense to limit the reach of the
matches (as it seems like it _can_ go wild).

I don't quite understand the regexps involved, so I cannot say whether
that specific limit is "crazy" or not.  But it's a defvar so anyone
who understands this stuff can provide a better value.



*** files.el    27 Jan 2006 09:50:16 +0100      1.802
--- files.el    03 Feb 2006 15:51:29 +0100      
***************
*** 2047,2052 ****
--- 2047,2055 ----
  If FUNCTION is nil, then it is not called.  (That is a way of saying
  \"allow `auto-mode-alist' to decide for these files.\")")
  
+ (defvar magic-mode-regexp-match-limit 4000
+   "Upper limit on `magic-mode-alist' regexp matches.")
+ 
  (defun set-auto-mode (&optional keep-mode-if-same)
    "Select major mode appropriate for current buffer.
  
***************
*** 2120,2128 ****
      (unless done
        (if (setq done (save-excursion
                       (goto-char (point-min))
!                      (assoc-default nil magic-mode-alist
!                                     (lambda (re dummy)
!                                       (looking-at re)))))
          (set-auto-mode-0 done keep-mode-if-same)
        ;; Compare the filename against the entries in auto-mode-alist.
        (if buffer-file-name
--- 2123,2135 ----
      (unless done
        (if (setq done (save-excursion
                       (goto-char (point-min))
!                      (save-restriction
!                        (narrow-to-region (point-min)
!                                          (min (point-max)
!                                               (+ (point-min) 
magic-mode-regexp-match-limit)))
!                        (assoc-default nil magic-mode-alist
!                                       (lambda (re dummy)
!                                         (looking-at re))))))
          (set-auto-mode-0 done keep-mode-if-same)
        ;; Compare the filename against the entries in auto-mode-alist.
        (if buffer-file-name


>
> Very oddly, it doesn't happen if I load file2.txt before file1.txt,
> so is there some form of leak in the "regexp matcher stack" ???

I still don't have a good explanation for this ODD behaviour.

Could it be that the problem is only seen when the regexp is
already compiled and thus found in the regexp cache?

Could someone please look into this problem -- it could look like some
form of memory corruption issue.



> In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2006-02-02 on kfs-l.imdomain.dk
> X server distributor `The XFree86 Project, Inc', version 11.0.40300000
> configured using `configure  'CFLAGS=-g -O0''

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

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