* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
@ 2016-08-26 20:17 Peder O. Klingenberg
2016-08-27 3:35 ` npostavs
2016-10-18 8:16 ` bug#24358: 25.1.50; Sam Halliday
0 siblings, 2 replies; 76+ messages in thread
From: Peder O. Klingenberg @ 2016-08-26 20:17 UTC (permalink / raw)
To: 24315
[-- Attachment #1: Type: text/plain, Size: 21543 bytes --]
I recently started using gnus-icalendar to handle meeting invitations.
Someone sent me an invitation that included a rather long email thread
in typical outlook style, and gnus errored out when trying to display
the article.
The backtrace showed that the error comes from the call
(re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t)
in icalendar--read-element (nil nil).
I reduced and anonymized the contents of the message, the problematic
section is attached to this bug report. The problem is reproducible for
me from emacs -Q by the following recipe:
C-x C-f calendar-event-problem.txt
<make sure cursor is somewhere in the first couple of lines>
M-: (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t)
Result:
Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
re-search-forward("\\(.*\\)\\(?\n[ ].*\\)*" nil t)
eval((re-search-forward "\\(.*\\)\\(?\n[ ].*\\)*" nil t) nil)
eval-expression((re-search-forward "\\(.*\\)\\(?\n[ ].*\\)*" nil t) nil)
funcall-interactively(eval-expression (re-search-forward "\\(.*\\)\\(?\n[ ].*\\)*" nil t) nil)
call-interactively(eval-expression nil nil)
command-execute(eval-expression)
Reducing the text size by about 1/3, or just moving the cursor a ways
down the buffer before evaling, eliminates the error.
From the same emacs -Q session:
max-specpdl-size is a variable defined in ‘C source code’.
Its value is 2930
Original value was 1300
Increasing max-specpdl-size to 20000 does not help, the problem still
occurs.
Strangely, the same recipe does not reproduce the error on os x, with a
build from master from 2016-08-12, but on my GNU/Linux machine, which is
where I run gnus and need this to work, it is 100% reproducible. I am
on Kubuntu 14.04.5, emacs is compiled with gcc (Ubuntu
4.8.4-2ubuntu1~14.04.3) 4.8.4.
Is this reproducible for anyone else, or do I need to dig deeper into my
environment? Any ideas on where to start digging?
In GNU Emacs 25.1.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2016-08-11 built on luna
Repository revision: 36a57c55f2b855bca704c26bf7d787b7b471fe16
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Ubuntu 14.04.5 LTS
Recent messages:
scroll-down-command: Beginning of buffer [3 times]
(Shell command succeeded with no output) [91 times]
Back to top level
When done with this frame, type C-x 5 0
Undo! [3 times]
calendar-event-problem.txt changed on disk; really edit the buffer? (y, n, r or C-h) r
ask-user-about-supersession-threat: File reverted: /home/pok/tmp/calendar-event-problem.txt
previous-line: Beginning of buffer [3 times]
Entering debugger...
Back to top level
Configured using:
'configure --prefix=/usr/local/emacs-git
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/site-lisp/:/usr/share/emacs/site-lisp
--with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
--with-pop=yes'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11
Important settings:
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Text
Minor modes in effect:
csv-field-index-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
diff-auto-refine-mode: t
show-paren-mode: t
yas-global-mode: t
yas-minor-mode: t
ido-everywhere: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
auto-fill-function: do-auto-fill
transient-mark-mode: t
Load-path shadows:
/home/pok/.emacs.d/elpa/org-20160822/org-macs hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-macs
/home/pok/.emacs.d/elpa/org-20160822/ob-dot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-dot
/home/pok/.emacs.d/elpa/org-20160822/ob-mscgen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-mscgen
/home/pok/.emacs.d/elpa/org-20160822/ob-clojure hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-clojure
/home/pok/.emacs.d/elpa/org-20160822/org-install hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-install
/home/pok/.emacs.d/elpa/org-20160822/org-faces hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-faces
/home/pok/.emacs.d/elpa/org-20160822/ob-scheme hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-scheme
/home/pok/.emacs.d/elpa/org-20160822/ob-haskell hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-haskell
/home/pok/.emacs.d/elpa/org-20160822/ob-sqlite hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sqlite
/home/pok/.emacs.d/elpa/org-20160822/ox-texinfo hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-texinfo
/home/pok/.emacs.d/elpa/org-20160822/ob-perl hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-perl
/home/pok/.emacs.d/elpa/org-20160822/ob-makefile hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-makefile
/home/pok/.emacs.d/elpa/org-20160822/ob-io hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-io
/home/pok/.emacs.d/elpa/org-20160822/org-docview hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-docview
/home/pok/.emacs.d/elpa/org-20160822/org-irc hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-irc
/home/pok/.emacs.d/elpa/org-20160822/ob-C hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-C
/home/pok/.emacs.d/elpa/org-20160822/ox-man hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-man
/home/pok/.emacs.d/elpa/org-20160822/org-capture hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-capture
/home/pok/.emacs.d/elpa/org-20160822/ob-table hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-table
/home/pok/.emacs.d/elpa/org-20160822/ob-sql hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sql
/home/pok/.emacs.d/elpa/org-20160822/org-list hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-list
/home/pok/.emacs.d/elpa/org-20160822/org-crypt hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-crypt
/home/pok/.emacs.d/elpa/org-20160822/org-attach hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-attach
/home/pok/.emacs.d/elpa/org-20160822/org-colview hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-colview
/home/pok/.emacs.d/elpa/org-20160822/org-id hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-id
/home/pok/.emacs.d/elpa/org-20160822/ob-plantuml hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-plantuml
/home/pok/.emacs.d/elpa/org-20160822/ox-publish hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-publish
/home/pok/.emacs.d/elpa/org-20160822/ob-tangle hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-tangle
/home/pok/.emacs.d/elpa/org-20160822/org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org
/home/pok/.emacs.d/elpa/org-20160822/org-indent hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-indent
/home/pok/.emacs.d/elpa/org-20160822/ox-ascii hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-ascii
/home/pok/.emacs.d/elpa/org-20160822/ob-matlab hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-matlab
/home/pok/.emacs.d/elpa/org-20160822/org-gnus hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-gnus
/home/pok/.emacs.d/elpa/org-20160822/org-feed hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-feed
/home/pok/.emacs.d/elpa/org-20160822/org-clock hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-clock
/home/pok/.emacs.d/elpa/org-20160822/org-element hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-element
/home/pok/.emacs.d/elpa/org-20160822/ob-screen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-screen
/home/pok/.emacs.d/elpa/org-20160822/ob hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob
/home/pok/.emacs.d/elpa/org-20160822/org-mobile hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mobile
/home/pok/.emacs.d/elpa/org-20160822/ox-latex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-latex
/home/pok/.emacs.d/elpa/org-20160822/ob-lisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lisp
/home/pok/.emacs.d/elpa/org-20160822/ob-calc hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-calc
/home/pok/.emacs.d/elpa/org-20160822/org-bibtex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-bibtex
/home/pok/.emacs.d/elpa/org-20160822/org-macro hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-macro
/home/pok/.emacs.d/elpa/org-20160822/org-agenda hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-agenda
/home/pok/.emacs.d/elpa/org-20160822/org-entities hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-entities
/home/pok/.emacs.d/elpa/org-20160822/ob-css hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-css
/home/pok/.emacs.d/elpa/org-20160822/ob-R hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-R
/home/pok/.emacs.d/elpa/org-20160822/org-mouse hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mouse
/home/pok/.emacs.d/elpa/org-20160822/org-timer hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-timer
/home/pok/.emacs.d/elpa/org-20160822/ob-java hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-java
/home/pok/.emacs.d/elpa/org-20160822/ob-gnuplot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-gnuplot
/home/pok/.emacs.d/elpa/org-20160822/ob-keys hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-keys
/home/pok/.emacs.d/elpa/org-20160822/ob-python hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-python
/home/pok/.emacs.d/elpa/org-20160822/org-compat hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-compat
/home/pok/.emacs.d/elpa/org-20160822/ob-fortran hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-fortran
/home/pok/.emacs.d/elpa/org-20160822/ob-exp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-exp
/home/pok/.emacs.d/elpa/org-20160822/ox-html hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-html
/home/pok/.emacs.d/elpa/org-20160822/ob-comint hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-comint
/home/pok/.emacs.d/elpa/org-20160822/org-src hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-src
/home/pok/.emacs.d/elpa/org-20160822/ob-scala hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-scala
/home/pok/.emacs.d/elpa/org-20160822/org-version hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-version
/home/pok/.emacs.d/elpa/org-20160822/org-loaddefs hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-loaddefs
/home/pok/.emacs.d/elpa/org-20160822/ob-emacs-lisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-emacs-lisp
/home/pok/.emacs.d/elpa/org-20160822/org-datetree hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-datetree
/home/pok/.emacs.d/elpa/org-20160822/ob-asymptote hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-asymptote
/home/pok/.emacs.d/elpa/org-20160822/ox-org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-org
/home/pok/.emacs.d/elpa/org-20160822/org-habit hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-habit
/home/pok/.emacs.d/elpa/org-20160822/ox hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox
/home/pok/.emacs.d/elpa/org-20160822/org-w3m hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-w3m
/home/pok/.emacs.d/elpa/org-20160822/ob-lob hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lob
/home/pok/.emacs.d/elpa/org-20160822/org-protocol hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-protocol
/home/pok/.emacs.d/elpa/org-20160822/ob-shen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-shen
/home/pok/.emacs.d/elpa/org-20160822/ob-maxima hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-maxima
/home/pok/.emacs.d/elpa/org-20160822/ob-ref hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ref
/home/pok/.emacs.d/elpa/org-20160822/ob-org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-org
/home/pok/.emacs.d/elpa/org-20160822/ob-latex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-latex
/home/pok/.emacs.d/elpa/org-20160822/ox-md hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-md
/home/pok/.emacs.d/elpa/org-20160822/org-mhe hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mhe
/home/pok/.emacs.d/elpa/org-20160822/ob-ledger hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ledger
/home/pok/.emacs.d/elpa/org-20160822/org-archive hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-archive
/home/pok/.emacs.d/elpa/org-20160822/org-ctags hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-ctags
/home/pok/.emacs.d/elpa/org-20160822/org-info hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-info
/home/pok/.emacs.d/elpa/org-20160822/ob-octave hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-octave
/home/pok/.emacs.d/elpa/org-20160822/org-pcomplete hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-pcomplete
/home/pok/.emacs.d/elpa/org-20160822/ob-ditaa hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ditaa
/home/pok/.emacs.d/elpa/org-20160822/org-plot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-plot
/home/pok/.emacs.d/elpa/org-20160822/ob-eval hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-eval
/home/pok/.emacs.d/elpa/org-20160822/org-table hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-table
/home/pok/.emacs.d/elpa/org-20160822/ox-beamer hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-beamer
/home/pok/.emacs.d/elpa/org-20160822/ox-odt hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-odt
/home/pok/.emacs.d/elpa/org-20160822/ob-core hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-core
/home/pok/.emacs.d/elpa/org-20160822/org-inlinetask hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-inlinetask
/home/pok/.emacs.d/elpa/org-20160822/org-rmail hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-rmail
/home/pok/.emacs.d/elpa/org-20160822/ox-icalendar hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-icalendar
/home/pok/.emacs.d/elpa/org-20160822/ob-lilypond hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lilypond
/home/pok/.emacs.d/elpa/org-20160822/ob-picolisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-picolisp
/home/pok/.emacs.d/elpa/org-20160822/ob-sass hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sass
/home/pok/.emacs.d/elpa/org-20160822/org-eshell hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-eshell
/home/pok/.emacs.d/elpa/org-20160822/ob-awk hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-awk
/home/pok/.emacs.d/elpa/org-20160822/ob-ruby hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ruby
/home/pok/.emacs.d/elpa/org-20160822/ob-ocaml hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ocaml
/home/pok/.emacs.d/elpa/org-20160822/ob-js hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-js
/home/pok/.emacs.d/elpa/org-20160822/org-footnote hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-footnote
/home/pok/.emacs.d/elpa/org-20160822/org-bbdb hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-bbdb
/usr/share/emacs24/site-lisp/latex-cjk-thai/thai-word hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/language/thai-word
Features:
(shadow emacsbug gnus-dup gnus-draft nndoc cus-edit ess-omg-l
ess-toolbar ess-mouse mouseme ess-menu ess-swv ess-noweb essd-els
ess-sas-d ess-sas-l ess-sas-a ess-sta-d ess-sta-l make-regexp ess-sp6-d
ess-dde ess-sp3-d ess-julia julia-mode ess-r-d ess-r-syntax
ess-r-completion ess-roxy essddr hideshow ess-help reporter
ess-r-package ess-s-l ess-site ess ess-inf ess-tracebug ess-mode
ess-noweb-mode ess-custom executable ess-generics ess-utils ess-bugs-l
ess-compat ess-lsp-l map esh-var esh-io esh-cmd esh-opt esh-ext esh-proc
esh-arg esh-groups eshell esh-module esh-mode esh-util dired-x autoload
tar-mode ffap php-mode flymake cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs hippie-exp vc
vc-dispatcher url-queue grep pulse vc-cvs slime-indentation
slime-cl-indent cl-indent slime-fancy slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree slime-scratch slime-presentations bridge
slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl elp slime-parse slime
lisp-mnt gud apropos etags xref project arc-mode archive-mode hyperspec
csv-mode magit-blame magit-stash magit-bisect magit-remote magit-commit
magit-sequence magit magit-apply magit-wip magit-log magit-diff
smerge-mode magit-core magit-autorevert autorevert filenotify
magit-process magit-popup magit-mode magit-git magit-section magit-utils
git-commit log-edit pcvs-util with-editor async-bytecomp async tramp-sh
tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell dash
eieio-opt speedbar sb-image ezimage dframe cal-china lunar solar cal-dst
cal-bahai cal-islam cal-hebrew holidays hol-loaddefs cal-iso bookmark pp
tabify org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
jka-compr image-mode org-bbdb org-w3m org-table org-archive org-clock
org-indent ob-ditaa ob-plantuml org-bibtex org-element avl-tree bibtex
org-colview org-crypt org-habit org-agenda help-fns radix-tree misearch
multi-isearch thingatpt debbugs-gnu add-log debbugs soap-client warnings
rng-xsd rng-dt rng-util xsd-regexp debug cus-start cus-load mailalias
bbdb-message footnote ecomplete flow-fill vc-git diff-mode sort
gnus-cite shr-color color shr svg dom browse-url mail-extr gnus-async
gnus-bcklg qp gnus-ml disp-table gnus-topic mm-archive url-http url-gw
url-cache url-auth pop3 nnrss xml mm-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
nndraft nnmh nnml utf-7 bbdb-gnus epa-file network-stream nsm starttls
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp
gnus-cache pok-gnus gnus-icalendar org-capture gnus-art mm-uu mml2015
mm-view mml-smime smime dig mailcap icalendar diary-lib diary-loaddefs
nnir gnus-sum gnus-group gnus-undo bbdb-mua bbdb-com crm bbdb bbdb-site
timezone gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7
netrc nnoo parse-time gnus-spec gnus-int gnus-range message sendmail
puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
gnus-win gnus nnheader subr-x gnus-util rmail rmail-loaddefs rfc2047
rfc2045 ietf-drums mail-utils wid-edit linum paren paredit pok-init
bugz-mode yasnippet org advice org-macro org-footnote org-pcomplete
pcomplete org-list org-faces org-entities time-date noutline outline
org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs gedcom
slime-autoloads reftex reftex-loaddefs reftex-vars edmacro kmacro ido
server filladapt dmacro mm-util mail-prsvr cl compile comint ansi-color
ring finder-inf tex-site info package epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib emacs-goodies-el
emacs-goodies-custom emacs-goodies-loaddefs easy-mmode mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 2485829 182861)
(symbols 48 72236 91)
(miscs 40 3269 4672)
(strings 32 298119 63000)
(string-bytes 1 12887713)
(vectors 16 103720)
(vector-slots 8 2448384 49706)
(floats 8 4985 2034)
(intervals 56 225770 627)
(buffers 976 190)
(heap 1024 299121 -1842968))
[-- Attachment #2: calendar-event-problem.txt --]
[-- Type: application/octet-stream, Size: 41457 bytes --]
DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\,\n\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn
nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn
nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\n\nNnnn nnnnnnn\,\n\nNnnnn Nnnnnnnn
| Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n\nNNN Nnnnnn Nnnnnnn\nNnnn Nnnnn Nnnn
n\,\n99 Nnnnnnnnnn Nnnnnn\,\nNnnnnn\, NN9N 9NN\n+999999999999 | Nnnn: nnnn
nnnnn@nnn.nnn\nnnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n\n\n\n\n__________________
___________________________\nNnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnn
nn.nn]\nNnnn: 99 Nnnnnn 9999 9:99 NN\nNn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n
Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn <nnnnnnnnn@nnn.nnn>\; +NNN
N <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\nNnnnnnn: Nn: [NNN] Nn: N
nnnnnn nnnnnnn nn NNN\n\n\nNnnnn\, N nnnn'n nnn nnn nnnn nnnnn nnn. 99:99
NNN nnn nnnnnn\, nnn 99:99 NNN nn nnnnnn nn nn n nnnnnn\, nnn N'n nnnnn n
nnnnnnnn. :)\n\n--\nNnn/Nnnnnnn\nNnnnn N. Nnnnnnnnnnn\nNnnnnnnn Nnnn NN\n\
nNn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n\n> Nn Nnnnn\,\n>\n> N
nnn nnn'nn nnnnnn n nnnn nnnn.\n>\n> Nnnnn nn nn nnnnnnnn nn nnnn Nnnnnnnn
nnnnn nnnn nnnn nn nnnn nn 9.99nn NNN nnnnn?\n>\n> Nnnn nnnnnnn\,\n>\n> Nn
nnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>\n> NNN Nnnnnn Nnnnnnn\n
> Nnnn Nnnnn Nnnnn\,\n> 99 Nnnnnnnnnn Nnnnnn\,\n> Nnnnnn\, NN9N 9NN\n> +99
9999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>
\n> -----Nnnnnnnn Nnnnnnn-----\n> Nnnn: NNN Nnnnnn\n> Nnnn: 99 Nnnnnn 9999
9:99 NN\n> Nn: 'Nnnnn N. Nnnnnnnnnnn' <nnn@nnnnnnnn.nn>\; NNN Nnnnnn\n> <
NNNNnnnnn@nnn.nnn>\n> Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn <nnn
nnnnnn@nnn.nnn>\;\n> +NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\
n> Nnnnnnn: NN: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>\n> NN Nnnnn\,\n>\n> Nn
nnnnnnn nnnnn nnn nn. Nnnnnn 9nn NNN nnnnn nn nnnnn. N nnnn nnnn nnn.\n>\n
> N’nn nnnnnnn nnn n nnnnnnn nnnnnn nnn nnnn nnnnnnnn nnnnnnn.\n>\n> Nnn
n nnnnnnn\,\n>\n> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>\n>
NNN Nnnnnn Nnnnnnn\n> Nnnn Nnnnn Nnnnn\,\n> 99 Nnnnnnnnnn Nnnnnn\,\n> Nnnn
nn\, NN9N 9NN\n> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n> nnnnnnnnn@nnn.
nnn | nnn.nnn.nnn\n>\n> -----Nnnnnnnn Nnnnnnn-----\n> Nnnn: Nnnnn N. Nnnnn
nnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n> Nnnn: 99 Nnnnnn 9999 9:99 NN\n> Nn: NNN
Nnnnnn <NNNNnnnnn@nnn.nnn>\n> Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnn
nnnn <nnnnnnnnn@nnn.nnn>\;\n> +NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@
nnn.nnn>\n> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>\n> Nn\, Nnnnn
.\n>\n> Nnnnnn nnnnnnn Nnnnnnnnn nnnn nnnn nn nnnn nnn nn\, nnnnnnnnn nn n
nnn\n> nnnn nn nnnn nnnnn nnn nnnn nnnnn. Nn nn nnnn nn nnnn nnnnn NN nnn
nn\,\n> nn nnn nn nn nnn nnnnn nnn nnnn? Nnnnnnn nnnnn 99 NNN nnnnn nnn n
n.\n>\n> Nnnnnn N nnnn nnn nn nnnn nnn nnnn nn? Nn nnnnnn nnnn nn +99 999
9 9999.\n>\n> --\n> Nnn/Nnnnnnn\n> Nnnnn N. Nnnnnnnnnnn\n> Nnnnnnnn Nnnn N
N\n>\n> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>\n>> Nn Nnnnn\
,\n>>\n>> Nnnnn\, nnnn nnnnnnn nnn nnnn nnnnnnnnnnnn nn nnn nnnn. Nnnn nn
nnn nnnnnnn nnnn nnnnnn nn nnnn nn nnnnnn nnnnnnnnn nnn NNN nnnnnnnnn.\n>>
\n>> Nn nnnnn nn nnnn nn nnnn nnnn nnnnnnnnn nnnn nnn nnnnnnnnnnnnn nnnnnn
\n>> nnnnn N nnnn nnnnnnnn. N nnnnn nnnnnn nn nnnnn nnn nnnnnnnn nnnnn\,\n
>> nnnn nnnn / nnnnnnnnnn nnnnnnnnn nnn nnnn nnnnnn nnnnnnnnn nnn nnn\n>>
nnnnnn / nnnnnnn / nnnnnn nnnnnnnnnnnnn\, nnnnnnnn nnnnn nnnnnn 99\n>> nnn
nnnn nnnn n nnnnn nnnn. Nnnn nn nnnn nnnnn nnnnnn nnn nn nnn nnnnn\n>> nnn
nnnn nnnn nnnnnnnnnn.\n>>\n>> Nnnnnn nnn nn nnnn nnnn nnnnnnnnnn nnnn / nn
nnn nnn nnn.\n>>\n>> Nnnn nnnnnnn\,\n>>\n>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nn
nnnnnn Nnnnn Nnnnnn\n>>\n>> NNN Nnnnnn Nnnnnnn\n>> Nnnn Nnnnn Nnnnn\,\n>>
99 Nnnnnnnnnn Nnnnnn\,\n>> Nnnnnn\, NN9N 9NN\n>> +999999999999 | Nnnn: nnn
nnnnnn@nnn.nnn\n>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>\n>> -----Nnnnnnnn N
nnnnnn-----\n>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>> Nn
nn: 99 Nnnnnn 9999 9:99 NN\n>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n>> Nn:
Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn <nnnnnnnnn@nnn.nnn>\;\n>> +NNN
N <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>> Nnnnnnn: Nn: [NNN] Nn
: Nnnnnnn nnnnnnn nn NNN\n>>\n>> Nnnnn nnnnn.\n>>\n>> N nnnn nnn nnnnnn nn
nn nnnn\, nnn N'n nnnnnn nnnnn nnnn nnnnnn nn nn\n>> nnn. N nnnnn nn nnn
nnnnn nnnnn nn nnn nnnnn nnnnnnnnn nnnn-nnn-nnnn\n>> nnn nnnn-nn-nnnn nnnn
nn. Nnn nn nnnnnnn nn nnn nnnnn nnnnn nnnnn?\n>> Nnn nnnn-nnn-nnnn\, nnn
nnnnnnnn nnnnnn nnnnnnn nn n nnnnnn\, nnnnn N\n>> nnn nnnnnnnnn n nnnnnn.
Nn nnnn nnnnnnn nn nnn nnn nnnnnnnnnn nnn\n>> nnnn nnnn nn nnnnn\, nn nnn
nnnn nnnn nn nnn nnnn nnnnnn nnnnn?\n>>\n>> Nnnnnn nnn nn nnnn nn nn\, nn
nnnn nnnnnnnn nnn nnnn nnnnn nnnnn nn\n>> nnnnnn nn nnnnnnnnnn nnn nnn nnn
nnnnnnn nnnnnn nnnn nn nnn nnnnn\n>> nnnn\, nnn nn nnnnn nn nnnn nn nnnn n
nn nnnnnnn nnn nnnnnnnnnn.\n>>\n>> N nnnn nnnnnnnnnnnn nnnnnn nnnnnn nnnnn
n\, nnnnn nnnnnn\, nnnnnnnnn\n>> nnnnn nnnnnnn nnn nnnnnn nnnnnnn\, NNN nn
nnnn\, nnnnnnnnn nnnnnnnn\n>> nnnnnnnnnn\, nnn nnnnn nnnnnnnnnnnnn.\n>>\n>
> Nnn nn nn nnnnnnn nn nnnnnnnnnn? Nn nn nnnn nn nnnn nnnn nnnnnn nnnn nn
nnnnnnn nn nnn?\n>>\n>> --\n>> Nnn/Nnnnnnn\n>> Nnnnn N. Nnnnnnnnnnn\n>> Nn
nnnnnn Nnnn NN\n>>\n>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n
>>\n>>> Nn Nnnnn\,\n>>>\n>>> Nnnnn - N nnnn nnnn nnnn nnnnn nnnnnnnnnn nn
nnn nnn nnnnnn nn nnn nnn nnnnnnnnnnn.\n>>>\n>>> Nnnnnn nnnnnnnn nnnnnnn.\
n>>>\n>>> Nnnn nnnnnnn\,\n>>>\n>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nn
nnn Nnnnnn\n>>>\n>>> NNN Nnnnnn Nnnnnnn\n>>> Nnnn Nnnnn Nnnnn\,\n>>> 99 Nn
nnnnnnnn Nnnnnn\,\n>>> Nnnnnn\, NN9N 9NN\n>>> +999999999999 | Nnnn: nnnnnn
nnn@nnn.nnn\n>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>\n>>> -----Nnnnnnnn N
nnnnnn-----\n>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>
Nnnn: 99 Nnnn 9999 9:99 NN\n>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n>>> Nn
: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn <nnnnnnnnn@nnn.nnn>\;\n>>> +
NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>>> Nnnnnnn: Nn: [NNN
] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>\n>>> Nn\, Nnnnn\n>>>\n>>> Nn nnnn nnnnnn
nnn nnnn nnnn NN nnnn. Nnnnn nnn nnnn n nnn nnnnn\n>>> nnnn nnnnn nnnnnnn
n NN nnnn nnnnnnn nnn nn nnnn\, nn nn nnnnn nn nnnn\n>>> nn nnnn nnnn nnnn
nn nnnn\, nnn nn'n nnn n nnnnnnnn.\n>>>\n>>> N nnn'n nnnnnnnn nnnn nn nnn
nnnn nnnnnnn nnn nnn nn nnnn\, nnn nnnnnnnnnn nn nnn nnnnn nnn nnnn NNN nn
nnnnnnnnnnn nn nn nnn nnnnn nnn.\n>>>\n>>> --\n>>> Nnn/Nnnnnnn\n>>> Nnnnn
N. Nnnnnnnnnnn\n>>> Nnnnnnnn Nnnn NN\n>>>\n>>> Nn Nnn\, Nnn 99 9999 nn 99:
99\, NNN Nnnnnn nnnnn:\n>>>\n>>>> Nn Nnnnn\,\n>>>>\n>>>> Nnnn nnn'nn nnn n
nnnn nnnnnnn.\n>>>>\n>>>> Nn nn nn nnnnnnn nnnnnnnnn\, nnnnn N nnn nnnnnn
n nn nnnn nnnnnn\n>>>> nnnnnnn. Nnn N nnnnnnn nnnnnnn nnn nnnn nn nnnnnnn
NN nnn NN nnnn\,\n>>>> nn nnn nn nnn nnnnn?\n>>>>\n>>>> Nnnnn nn nnnn nnnn
nn\, N nnnn nn nnnnn nnn nnnn nnnnn nnnn nnnnnnnnn nn nnnn nnn nnnnnnnn NN
N nnnnnnnnn nnn nn nnn nn nnnn nnnnn.\n>>>>\n>>>> Nnnn nnnnnnn\,\n>>>>\n>>
>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>\n>>>> NNN Nnnnn
n Nnnnnnn\n>>>> Nnnn Nnnnn Nnnnn\,\n>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>> Nnnn
nn\, NN9N 9NN\n>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>> nnnnnnnn
n@nnn.nnn | nnn.nnn.nnn\n>>>>\n>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>> Nnnn:
Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>> Nnnn: 99 Nnnn 9999 9:
99 NN\n>>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n>>>> Nn: Nnnn Nnnnn <nnnnn
n@nnn.nnn>\; Nnnn Nnnnnnnn <nnnnnnnnn@nnn.nnn>\;\n>>>> +NNNN <NNNN@nnn.nnn
>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnn
nnnn nn NNN\n>>>>\n>>>> Nn\, Nnnnn.\n>>>>\n>>>> Nnnn nnnn nnnnnnnnn :)\n>>
>>\n>>>> Nn nnn nnnnnn nnnnnnnnn-nn-nnnnnn nnn/nn nnnn-nnn-nnnn nnnnnn? N
\n>>>> nnnnn nnnn nn nnnn\, nnn nnn n nnnnnn nnnnnnnn nnnnn nnn nnnnnnnnn
-\n>>>> nnnn nnnn nnnnnnnn nnnnnnn nnn nnnnn nnnn nnn nnnnnnnnnnnn\, nn\n>
>>> nnnnnnn nnnn nnnnn nnn nn nnnnnn?\n>>>>\n>>>> --\n>>>> Nnn/Nnnnnnn\n>>
>> Nnnnn N. Nnnnnnnnnnn\n>>>> Nnnnnnnn Nnnn NN\n>>>>\n>>>> Nn Nnn\, Nnn 99
9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>\n>>>>> Nn Nnnnn\,\n>>>>>\n>>>>> N
nnnnn nnn nnnn nnnnn. N nnnnnn nnnn nn nnnnnn nn nnnnnnnn nn nnn nnnn nnnn
nnnnnnn nn nnn nnnnnn nn.\n>>>>>\n>>>>> Nnn nn nnnnn nnnn Nnn\, nnn nn nnn
nnnnn nn nn Nnnnnn.\n>>>>>\n>>>>> Nnnn n nnnnn nnnnnnn.\n>>>>>\n>>>>> Nnn
nn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>\n>>>>> NNN Nnnnnn Nn
nnnnn\n>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>> Nnnnn
n\, NN9N 9NN\n>>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>> nnnnnnn
nn@nnn.nnn | nnn.nnn.nnn\n>>>>>\n>>>>> Nnnnn\n>>>>>\n>>>>> -----Nnnnnnnn N
nnnnnn-----\n>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>
>>> Nnnn: 99 Nnnn 9999 9:99 NN\n>>>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n
>>>>> Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>> <nnnnnnnnn@nn
n.nnn>\;\n>>>>> +NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>>>>
> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>\n>>>>> Nn\, Nnnnn.\
n>>>>>\n>>>>> Nn nnnnnn nnnnn nnn nnn nnn nn 9999 NN. N nnnnnnnn nnn nnn\
n>>>>> nnnnnnnn nnnnnnn nnnnn\, nnn nnn nnnnnn nn nnn nnnnnnnnn nnnnnn\n>>
>>> nnnnnnn. Nn nnn\n>>>>> NnnNnn(99) nnn nn 9. Nnnnn nnnn nn nnnnn nnn
nnnn nnnnn nnnn nnn\n>>>>> nnnnnnn nnnnnnnn nnnnn\, N nnnnn nnnnnn NnnNnn
nn nnnnnn nn 9999\,\n>>>>> nn nn nnn nn nnn nnnnnnnn nnnnnnn.\n>>>>>\n>>>>
> Nn nnnn nn nnnnnnnn nn nnn nnnnnnn nnnnnnnnnnn\, nn nnnn nnnn nnnnnnnnn
nn nnn nnnn nn nnnnnnnnnn?\n>>>>>\n>>>>> (Nnnn n nnnn nnnnnnn\, N'n nnnnnn
n nnn nnn\, nnnn nnnnnnnn nnnn nn\n>>>>> nnnnnn.)\n>>>>> --\n>>>>> Nnn/Nnn
nnnn\n>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>> Nnnnnnnn Nnnn NN\n>>>>>\n>>>>> Nn
Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>\n>>>>>> Nn Nnnnn\,\n
>>>>>>\n>>>>>> N nnn nnn nnnnn nnnnnnnn. N nnnn nnnnnnnnn nnnn nnn nnnnnnn
nnnn nnnn nnnn nn nnnn nnn nnnnnnnnn nnnnnnnnn nnnnnnnnnn nn nnnnn nnn nnn
nnnnnn nnnnnnn:\n>>>>>>\n>>>>>> 9 nn 99 === nnnnnnnn\n>>>>>> 999 nn 999 ==
= nnnn nnnnnnnn\n>>>>>> 999 nn 9999 === nnnnnnn nnnnnnn 999 nnn nnnn nnnnn
nn\n>>>>>> 9999 nn 9999 === nnnnnnn nnnnnnn 999 nnn nnnnnn nnnnnnn\n>>>>>>
9999 nn 9999 === nnnnnnn nnnnnnn 999\, 999 \, 999 \, 999 nnn nnnn\n>>>>>>
nnnnnnn\n>>>>>> 9999 nn 9999 === nnnnnnn nnnnnnn 999\, 999\, 999\, 999 nn
n nnnnnn\n>>>>>> nnnnnnn Nnnn 9999 === nnnnn nnnnn.\n>>>>>>\n>>>>>> Nn nnn
nnnnn nnnn nn nnnnnn nnn nnnnnnnn nn nnnnn nnn nnnnnnnnnn nnnnn nnn nnnnn
n nnn nnn nnnnnnnnn nnnnnnnnn nn nnnnnnnnn.\n>>>>>>\n>>>>>> Nnnn nnnnnnn\,
\n>>>>>>\n>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>
\n>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>> 99 Nnnnnnnn
nn Nnnnnn\,\n>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>> +999999999999 | Nnnn: nnnnnn
nnn@nnn.nnn\n>>>>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>\n>>>>>> -----N
nnnnnnn Nnnnnnn-----\n>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnn
nn.nn]\n>>>>>> Nnnn: 99 Nnnn 9999 9:99 NN\n>>>>>> Nn: NNN Nnnnnn <NNNNnnnn
n@nnn.nnn>\n>>>>>> Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>>>
<nnnnnnnnn@nnn.nnn>\;\n>>>>>> +NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn
@nnn.nnn>\n>>>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>\n>
>>>>> Nnnnn nnnnn\, Nnnnn.\n>>>>>>\n>>>>>> N nnnn nnnnn nnnnnnnn n nnnn nn
nnn nnn nnn nn 99 Nnnn Nnnn. Nnn\n>>>>>> nnnnn nnn nnnnnnnn nnnn nnn nnnn
"NnnnnNnnnnn Nnnnnn : NNNNNN\n>>>>>> NNNN nnn nnnnnn nn nnn<". Nnn nn nn
nn?\n>>>>>>\n>>>>>> --\n>>>>>> Nnn/Nnnnnnn\n>>>>>> Nnnnn N. Nnnnnnnnnnn\n>
>>>>> Nnnnnnnn Nnnn NN\n>>>>>>\n>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN
Nnnnnn nnnnn:\n>>>>>>\n>>>>>>> Nn Nnnnn\,\n>>>>>>>\n>>>>>>> Nnnn nnn nnn
n nnnn nnnn nnn. Nnnn nn nnnn nn nn nnn nnnnnnn nnnnnnn nnnnnnNnnNN.\n>>>>
>>>\n>>>>>>> Nnnnnn nnn nn nnnn nn N nnn nnnnnn nnnnnn nnnnnnn.\n>>>>>>>\n
>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>\n>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnn
nnn Nnnnn Nnnnnn\n>>>>>>>\n>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>> Nnnn Nnnnn
Nnnnn\,\n>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>
> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>> nnnnnnnnn@nnn.nnn | nnn
.nnn.nnn\n>>>>>>>\n>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>> Nnnn: Nnnnn
N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>> Nnnn: 99 Nnnn 9999 9:99
NN\n>>>>>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n>>>>>>> Nn: Nnnn Nnnnn <nn
nnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>>>> <nnnnnnnnn@nnn.nnn>\;\n>>>>>>> +NNN
N <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>>>>>>> Nnnnnnn: Nn: [NN
N] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>\n>>>>>>> Nn.\n>>>>>>>\n>>>>>>> N'nn
nnnn nn nnnnnnn nnn n nnnnnn nn nnnnn.\n>>>>>>>\n>>>>>>> N'n nnnnnnnnn nn
nnnnnnnnnn nnnnnn nn nn nnn NNN nnnnnn. Nnn nnnnn nnn\, nn N nnnnnnnnn\,
nn nnn nnnn nnn nnnnnnNnnNN nn nnnnn.\n>>>>>>>\n>>>>>>> N nnnn nnnnn nnnnn
nn nnnnnn nnnnnnn.\n>>>>>>>\n>>>>>>> --\n>>>>>>> Nnn/Nnnnnnn\n>>>>>>> Nnnn
n N. Nnnnnnnnnnn\n>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>\n>>>>>>> Nn Nnn\, Nnn
99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>>>\n>>>>>>>> Nn Nnnnn\,\n>>>>>>
>>\n>>>>>>>> Nnnnn nnn nnnnnnn nn nnnnn nnnnn nnn nn nnnnnn.\n>>>>>>>>\n>>
>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>\n>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnn
nnnn Nnnnn Nnnnnn\n>>>>>>>>\n>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>> Nnnn Nn
nnn Nnnnn\,\n>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>>> Nnnnnn\, NN9N 9NN\n
>>>>>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>>> nnnnnnnnn@nnn.n
nn | nnn.nnn.nnn\n>>>>>>>>\n>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>
Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>> Nnnn: 99 Nnn
n 9999 9:99 NN\n>>>>>>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\n>>>>>>>> Nn:
Nnnn Nnnnn <nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>>>>> <nnnnnnnnn@nnn.nnn>\
;\n>>>>>>>> +NNNN <NNNN@nnn.nnn>\; +NN Nnnnnn <Nnnnnnnn@nnn.nnn>\n>>>>>>>>
Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>\n>>>>>>>> Nn nnnn
n.\n>>>>>>>>\n>>>>>>>> N nnnn nnnnnnnnnnnn\, nnn nn nnnnnnnnn nnnnn nnnn n
nn nnnnnn.\n>>>>>>>> Nn nnnnnnn nn nn nnnn nn nn nnn nnnnnn nnn nnnnnnnnnn
nnnnnnnn\n>>>>>>>> nn nnnnnnnnn nn nnnnn nnnnnnn. Nn nnnn nnnn nnnn nn n
nnnnnnnnn\n>>>>>>>> nn nn nnn?\n>>>>>>>>\n>>>>>>>> N nnnnnn nn nn 999.999.
99.999:9999 nn nnnnnnnnnnnnn 99:99 NNN\,\n>>>>>>>> nnnn nnnnNnn NNNN/NNN n
nn nnnnnnNnnNn NNNN. Nn nnnnnnn nnn\n>>>>>>>> nnnnnnNnnNn nnnn nn nn nnnn
nn nnn nnnnn nnnnnnnn nnnnnnnn?\n>>>>>>>>\n>>>>>>>> --\n>>>>>>>> Nnn/Nnnn
nnn\n>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>\n>
>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnnn N. Nnnnnnnnnnn nnnnn:\n>>>>>
>>>\n>>>>>>>>> Nn\, Nnnnn.\n>>>>>>>>>\n>>>>>>>>> Nnnnn nnn\, N'nn nnn nn n
n nnn nnn nnnnn nnnnnnn\, nnnnnn nnnnnnnn.\n>>>>>>>>>\n>>>>>>>>> --\n>>>>>
>>>> Nnn/Nnnnnnn\n>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>> Nnnnnnnn Nnnn
NN\n>>>>>>>>>\n>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:
\n>>>>>>>>>\n>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>\n>>>>>>>>>> N'nn nnnn nnnnn
nn nnn NN nnn nnnnnn nnn nnnnnnn. Nnnnnn\n>>>>>>>>>> nnnnnn 999.999.99.999
. (Nnnn 9999)\n>>>>>>>>>>\n>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>\n>>>>>>>>
>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>>>>>\n>>>>>>>>
>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>>>>>> 99 Nnnnnn
nnnn Nnnnnn\,\n>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>> +999999999999 | Nn
nn: nnnnnnnnn@nnn.nnn\n>>>>>>>>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>>
>>>\n>>>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>>> Nnnn: Nnnnn N. Nnnn
nnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>>>> Nnnn: 99 Nnnn 9999 99:99 NN\n
>>>>>>>>>> Nn: Nnnn Nnnnn <nnnnnn@nnn.nnn>\n>>>>>>>>>> Nn: NNN Nnnnnn <NNN
Nnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>>>>>>> <nnnnnnnnn@nnn.nnn>\; +NNNN <N
NNN@nnn.nnn>\; +NN Nnnnnn\n>>>>>>>>>> <Nnnnnnnn@nnn.nnn>\n>>>>>>>>>> Nnnnn
nn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>\n>>>>>>>>>> Nnnnnnnnn
n\, nnnn nn nnnnnnn nnnn nn nnnnn nnnn nnn. Nnnnnn!\n>>>>>>>>>> --\n>>>>>
>>>>> Nnn/Nnnnnnn\n>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>> Nnnnnnnn Nn
nn NN\n>>>>>>>>>>\n>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnn Nnnnn n
nnnn:\n>>>>>>>>>>\n>>>>>>>>>>> Nnn\, n nnnnnnnnn nnnnnn nnnn nnnnnn nn nnn
nnnnnnnnnnnn nn nnn nnnnn nnnnnnnnnn nn nnn nnnnnn nnnn. Nn nnnn nnn nnn'
n nnnnnn nn nn nnnnnn?\n>>>>>>>>>>>\n>>>>>>>>>>> Nnnnnnn\,\n>>>>>>>>>>>\n>
>>>>>>>>>> Nnnn Nnnnn\n>>>>>>>>>>>\n>>>>>>>>>>> N: +99 (9)99 9999 9999 | N
: +99 (9)99 9999 9999\n>>>>>>>>>>>\n>>>>>>>>>>> -----Nnnnnnnn Nnnnnnn-----
\n>>>>>>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>
>>>> Nnnn: Nnnnnnnn\, Nnnn 9\, 9999 99:99 NN\n>>>>>>>>>>> Nn: Nnnn Nnnnn\n
>>>>>>>>>>> Nn: NNN Nnnnnn\; Nnnn Nnnnnnnn\; +NNNN\; +NN Nnnnnn\n>>>>>>>>>
>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>>\n>>>>>>>>>>>
Nn\, Nnnn.\n>>>>>>>>>>>\n>>>>>>>>>>> Nnnnnnnnnnnn nnnnnn nnnnnn nn nnnn n
n nnnnnn@nnnnnnnn.nn\, nnnnn nn n nnnnnnnnnnnn nnnn nnn nnnnn nnnn nnn.\n>
>>>>>>>>>>\n>>>>>>>>>>> Nnnn nnn nnnn nnnnnn NNN nnnnnn nnnn nnnnnnnn nnnn
nnnnn nnnn n nnnnnnnnn nnnnnn?\n>>>>>>>>>>>\n>>>>>>>>>>> --\n>>>>>>>>>>> N
nn/Nnnnnnn\n>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>>> Nnnnnnnn Nnnn NN
\n>>>>>>>>>>>\n>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnn Nnnnn nnnn
n:\n>>>>>>>>>>>\n>>>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nn NN
N nnnnnn\, N nnn nnnnnnn nnnn nn nnnn nnnnnn nnnn nnnn\n>>>>>>>>>>>> nnnnn
nn n nnnnnnnnn nnnnnn. Nnn nnnnnnnnnnnn nnnn nn\n>>>>>>>>>>>> nnnnnnnnnnn
nn nn nnnnn nnnnnnnnnnnn\, nnnnnn nnn nn nnnn\n>>>>>>>>>>>> nnn nnnnnn nn
nnn nnnnnnnnnn nn nnnn nnnnn.\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nnn nnnnnnn nnn
nnnnn nn NNN/NNN nnnnnn nn nnn nnnn nnnn nnnn nn nnnnn.\n>>>>>>>>>>>>\n>>>
>>>>>>>>> Nnnnnnn\,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nnnn Nnnnn\n>>>>>>>>>>>>\n
>>>>>>>>>>>> N: +99 (9)99 9999 9999 | N: +99 (9)99 9999 9999\n>>>>>>>>>>>>
\n>>>>>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>>>>> Nnnn: Nnnnn N. Nnn
nnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>>>>>> Nnnn: Nnnnnnnn\, Nnnn 9\,
9999 99:99 NN\n>>>>>>>>>>>> Nn: NNN Nnnnnn\n>>>>>>>>>>>> Nn: Nnnn Nnnnnnnn
\; +NNNN\; +NN Nnnnnn\n>>>>>>>>>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn
nn NNN\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nn\, Nnnnn.\n>>>>>>>>>>>>\n>>>>>>>>>>>
> Nn nnnnnnnnnnn nnnn nnnnnnnnn nnnn nnnn.nnnnnnnn.nn\, 99.99.999.99.\n>>>
>>>>>>>>>\n>>>>>>>>>>>> --\n>>>>>>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>>>> Nnnnn N
. Nnnnnnnnnnn\n>>>>>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>>>>>\n>>>>>>>>>>>> N
n Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>>>>>>>>\n>>>>>>>>>>
>>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> N nnnn nnnnnnnn nnn nnnnnnn n
nnn nn nnnn nnnnnn nnn nn nnnn nnnnnnnnn nnnnn N nnnn nnnnnnnnnnn nn nnn:\
n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn n nnnnnnn nnnnnnn nnn NNN/NNN nnnnn
n nn nnnn nnnnnn? Nnn nn nnnn nnnnnn nnnnnnnnnnnnn nnnnnnnnn nn nnnn nn n
nnnnnnnn nnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnnn nnnn nn nnnnnnn nnn
nn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn nnnnnn nnn nn nnnnnn NN 999.99.
999.99 nnnn nnn\n>>>>>>>>>>>>> nnnnnnnn nnn nnnn NNN nnnnnnn. Nnnnn nnn nn
nnnn nnnnnn nnnn NN nnn nnnn nn nnnnnnnnnn nnnn nn nn nnn nnnnnnnnnn nnn n
n nnn nnnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn nnnn NNN nnnnnnn nn nnnn
nn 9.9. Nnn99 nn nnn nnnnnnnnn\n>>>>>>>>>>>>> nnn nn nnnnnnnnn nn nnnn nn
nn nnnnnnnn. Nnn9999 nn nnnnnnnnn nnn nnn nnnnnnnnnn\, nnnnnnn\, nn nnn nn
nnnnn nn nnnn nnnnnn 9999=NNN.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nn nnnnnnn
n nn nnnnnnnn nnnnnnnnnn nnn NNN nn Nnn nn nnn nn nnn nnnnnnn nn nnn nnnnn
.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnn nnn9 nnn nnnnnnnnnn nnnn nn nnnn nn
nnn nnn nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>>>>
\n>>>>>>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>>
>>>>>>\n>>>>>>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn
n Nnnnn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>
>>>>>>>>>\n>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> +
999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> nnnnn
nnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> -----Nnnnnnnn Nnn
nnnn-----\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn
:nnn@nnnnnnnn.nn]\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn: 99 Nnnn 9999 9:99 NN
\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn: Nnnnn Nnnnnnnn <nnnnnnnnn@nnn.nnn>\n>>>
>>>>>>>>>>\n>>>>>>>>>>>>> Nn: NNN Nnnnnn <NNNNnnnnn@nnn.nnn>\; Nnnn Nnnnnn
nn\n>>>>>>>>>>>>> <nnnnnnnnn@nnn.nnn>\;\n>>>>>>>>>>>>> +NNNN <NNNN@nnn.nnn
>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnnnn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\
n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn
n nnnnnnnnn nnnnn nn nnnn nnnn nnnnn nnnnnnnnnnnnnnn\, N nnnnn.\n>>>>>>>>
>>>>> Nn nn nnnn nn nnnnnnn 99=NNNN\;9999=NNN\, nn nn nnn nnnnnnn nn n Nnn
nnnNnnNN nnn Nnnnnnnn nnnnn nn n NNN nnnnn? Nnn nnn nnnn NNN nnnnnnn nn n
nnnn 9.9\, nnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnnnn nnn nnn nnnnn
n nn nnn 99 nnn nnnnnnnnn\, nn nnnn nnnnnn nn nn.\n>>>>>>>>>>>>>\n>>>>>>>>
>>>>> Nn nnn'n nnnnnnnnn nnnnnnn n NnnnNnNnnnn\, nnn nn nnnnnnnn nn n nnn
nnnnn. Nnnn nn nnnnn nnnnnnn nn nnn nnnnnn nn nnn nnn nnnnnn?\n>>>>>>>>>>
>>>\n>>>>>>>>>>>>> Nn nnn nn nnnnnnnnnn nn nnnnnnnn nn nnnnnnn nnnn nnnnn\
,\n>>>>>>>>>>>>> nnn nnnnnn nnn nnnnnn nn nn nnnnn NNN nnn/nn NNN nnnnnn\,
\n>>>>>>>>>>>>> nn N nnnnnnn nn nnn nnnnnnnnn nnnnnnnnn NNN nn nnnnnnn nnn
nnnnnn nnnn nnn\, nnn nnnnnn nn nnnn nnnnnnnn nn nnnnnnnnn nnnnnn. Nn nn
nnn n nnnnnnn nnnnnnn nnn NNN/NNN nnnnnn nn nnnn nnnnnn? Nnn nn nnnn nnnn
nn nnnnnnnnnnnnn nnnnnnnnn nn nnnn nn nnnnnnnnn nnnnnnn?\n>>>>>>>>>>>>>\n>
>>>>>>>>>>>> Nn nnnn nnn nnn Nnnnnnn(9) nnn nnn nnnnn nn nnnnnnn nnn nnnnn
nnnnn nnnnnnn. Nnnn nnnn nnnnnnnn nn nnnn nn nnn nnn nnnnnn?\n>>>>>>>>>>>
>>\n>>>>>>>>>>>>> --\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>>
>>>\n>>>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn
nnnn Nnnn NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\,
Nnnnn N. Nnnnnnnnnnn nnnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nn.\n>>>>>>>>>
>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnn nnnnn nnn nnnnn\
, N nnn nnn nn nnn nnnnnn nnn nnnn\n>>>>>>>>>>>>>> nn nnnn nnnn\,\n>>>>>>>
>>>>>>\n>>>>>>>>>>>>>> nnn nnnnn nnnn nn nnnnnnnnn nnnnnnnn nn nn nnnnn nn
nnnnnn.\n>>>>>>>>>>>>>> N nn nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> nnnnnnnnn
nnn nnnnnnnnnnnnn nnn nnnn nn\, nnn nnnn nnn\n>>>>>>>>>>>>>> nnnn nn nnn
nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> nnn nnnnnnnnn.\n>>>>>>>>>>>>>\n>>>>>>>
>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> N nnnn nnn nnnnnnnnn nnnnnnnn\, nnn
nnnnnn nnn NNN nnnnnnn\n>>>>>>>>>>>>>> nnn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>>
>>>>>>>> nn: nnnnn NN\, nnn nnn nnn nnnnnnnnn nnnnnnnnnnn nnn NNN\n>>>>>>>
>>>>>>> nn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnnnnn?\n>>>>>>>>>>>>
>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> --\n>>>>>>>>>>>>>\n>>>>>>
>>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n
>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>
>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnnn N
nnnnnnn nnnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>
>>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>
>>>> Nnnnnn nnn nn nnnn nn nnnnnnnn nnnnn nn nnnnnnn\, nnn N nnnn nn nnnnn
nn nnnnnn. Nn nnn nnnnn nnnnnn nn nnnnnnn nnnn nnn nnnnn nnnnnn nnnn nnnn
.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn nnn
nnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnn
nn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>
>>>> [Nnnnnnnnnnn: Nnnnnnnnnnn:\n>>>>>>>>>>>>>>> nnn:nnnnn999.nnn@99NN9999
.99999N99]\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>>
>>\n>>>>>>>>>>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 99
Nnnnnnnnnn Nnnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>
>>>>>>>>>>\n>>>>>>>>>>>>>>> +999999999999 | Nnnn:\n>>>>>>>>>>>>>>> +nnnnnn
nnn@nnn.nnn<nnnnnn:nnnnnnnnn@nnn.nnn>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn
nnnnn@nnn.nnn<nnnnnn:nnnnnnnnn@nnn.nnn> |\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>
nnn.nnn.nnn<nnnn://nnn.nnn.nnn/>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>
>>>>>\n>>>>>>>>>>>>>>> Nnnn: Nnnnn Nnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>
> Nnnn: 99 Nnn 9999 99:99 NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nn: 'nnn@nnnn
nnnn.nn' <nnn@nnnnnnnn.nn>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nn: +NNN Nnnnnn
<NNNNnnnnn@nnn.nnn>\; Nnnn Nnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> <nnnn
nnnnn@nnn.nnn>\; +NNNN <NNNN@nnn.nnn>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn
nnn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>
\n>>>>>>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>
>\n>>>>>>>>>>>>>>> N nnnn nnnn nnnnn nnnn nnnnnnn nnnnnnnnnnn nn nnnnnnn n
n nnnnnnn nnnnnnn nnnnnnn nnnnnnn nnnnnnnnnn nnn NNN.\n>>>>>>>>>>>>>\n>>>>
>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> N nnnnnnnnnn nnnn nnn nnn nnnn
nnn nn nnnnnn n nnnnnnnnn\n>>>>>>>>>>>>>>> NNN NNN\, nnn\n>>>>>>>>>>>>>\n>
>>>>>>>>>>>>>> nn nnnn nnnn nn nnnn nnn nnnnnnn nnn nnnn nnn nnnnn. N\n>>>
>>>>>>>>>>>> nnnnnnnnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn nn nnnnnn
n NNN nnnnnn nnnn. N nnnn nnnnnnnn nnn\n>>>>>>>>>>>>>>> nnnnnnn NNN\n>>>>>
>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnnnn\, nnnnn nnn nnn nnnn nnnnnn - Nnn
NNN\n>>>>>>>>>>>>>>> nnnnnn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn
nnnnnnnnn nn n NNN nnnnnnnn nnnnn\, nn nnnn nn nnn\n>>>>>>>>>>>>>>> NNN NN
N nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nnn nnn NNN nnnnnn nn nn nnnnnnn
.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> N nnn nn
nnnnnnnnn nnnn n NNN nnnnnnn nnn nn nnn nnn nn nnnnn. Nn nnn nnnn nnnn nn
nn nnnnnnn\, nn nnnnn n nnn NNN nnnnnnn nnn nnn\, nn nnn nnnnnn.\n>>>>>>>>
>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnNnnnNN=NNNN\n
>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> NnnnnnNnnnNN=NNN\n>>>>>>>>>>>>>\n>>>>>>>>>>
>>>>> Nnnn=9999\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>
>>>>> N nnnn nnnnnnn nn nnnnnnn nnnn nnn.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\
n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>
>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn
Nnnnn Nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> [Nnnnnnnnnnn: Nnnnnnnnnnn:\n>
>>>>>>>>>>>>>> nnn:nnnnn999.nnn@99NN9999.99999N99]\n>>>>>>>>>>>>>\n>>>>>>>
>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn Nnnnn Nnn
nn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>>>>>>>>
\n>>>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +99999
9999999 | Nnnn:\n>>>>>>>>>>>>>>> +nnnnnnnnn@nnn.nnn<nnnnnn:nnnnnnnnn@nnn.n
nn>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnn@nnn.nnn<nnnnnn:nnnnnnnnn@nnn
.nnn> |\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnn.nnn.nnn<nnnn://nnn.nnn.nnn/>\n
>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn n-nnnn
nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn\n>>>>>>>>>>>>>>> nnn nnnnnnnnnn
\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn
nnnnnnn\n>>>>>>>>>>>>>>> nnnnnnnnnnn nnnn nn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>
>>> nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn\n>>>>>>>>>
>>>>>> nn nnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnnn nn nnn nn nnn
nnnnnnn. Nnn nnnnnnnnnnnn nnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnn
nnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn\n>>>>>>>>>>>>>>> nnnnnnnnnnn nn
\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn
nnn nnnn\n>>>>>>>>>>>>>>> nnnnnnnn nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn
nnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn\n>>>>>>>>>>>>>>> nnnnnnnnnn
n nn nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> n-nnnn\, nnn nnnnnnnnnnn nnnnn
n nn nnnnnnn nnnn n-nnnn\,\n>>>>>>>>>>>>>>> nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>
>>>>> nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn\n>>>>>>>>>>>
>>>> nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnn nn nnnn n-nnnn\, nnn
nnnn nn nnnn nnnnnnn nnnnnn nn\n>>>>>>>>>>>>>>> nnnnnnnnn nn\n>>>>>>>>>>>>
>\n>>>>>>>>>>>>>>> n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn\n>>>>
>>>>>>>>>>> nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnn nnn nnnn
nnnnnnn nnnnnnnnn NNN'n nnnnnnnn nnn\n>>>>>>>>>>>>>>> nnnnnnnn\,\n>>>>>>>>
>>>>>\n>>>>>>>>>>>>>>> nnnnnn nnnnn nn nnn nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>
>>>>>>>>>> nnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>
>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>
>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn\n>>>>>>>>
>>>>> nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn\n>>>>>>>>>>>>>
nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\,\n>>>>>>>>>>>>> nnn
nnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn\n>>>>>>>>>>>>> nnn n
n nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnn
nnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nn
n nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnn
nnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\,
nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnn
nnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnn
nnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnn
nnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnn
nnnnn nnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-
nnnnnnnnnnn\n>>>>>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnn
n nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnn
nnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnn
nn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnn
nnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnn
nnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnn
n\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnn
n nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnn
n nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnn
nnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnn
nn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nn
nnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>>>>>\n>>>>>>>>>>>> n
nnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>>>>>> Nnnn n-nnnn nnn nn
n nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn
nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\,
nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnn
n. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn
nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnn
nnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn
nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnn
nnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn
n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnn
nnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnn
nnnnnn NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:
\n>>>>>>>>>>>\n>>>>>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>
>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnn
nnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn
nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnn
nnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnn
nnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn
nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn
nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnn
nn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnn
nn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnn
nnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnn
nnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn n
nnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>>>\n>>>>>>>>>> nnnn://nnn.nnn.nnn/nnn
nn/nnnnnn-nnnnnnnnnnn\n>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnn
nn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnn
nn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn
nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\
, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn n
n nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn n
n nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnn
nnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (
nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnn
n nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nn
nnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn
nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>\n>>>>>>>> nnn
n://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>> Nnnn n-nnnn nnn nnn nnnn
nnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnn
nnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnn
n nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn
nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn n
nnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn n
nnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn
n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\
, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnn
n\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn
nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn
NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>
>>>\n>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>\n>>>>>> N
nnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnn
nnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnn
nn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn
nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnn
n nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn.
Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnn
n nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-
nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnn
nn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn
n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nn
n nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nn
n nnnnnnnnn nnnn:\n>>>>>>\n>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnn
nnn\n>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnn
nnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn n
n nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnn
nnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nn
nnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn
nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnn
nn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnn
nnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nn
nnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn n
nnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nn
nnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nnnnnnnn\, nnnnnn
nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>\n>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnn
n-nnnnnnnnnnn\n>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn
nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnn
nn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn
nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnn
nnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn
nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nn
nnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnn
nn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn n
nnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nn
nnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnn
nnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nnnnnnnn
\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>\n>>>> nnnn://nnn.nnn.nnn/nnnn
n/nnnnnn-nnnnnnnnnnn\n>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnn
n nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnn
nnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnn
nn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnn
nnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnn
nnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnn
n\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnn
n nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnn
n nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnn
nnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnn
nn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn nn
nnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>\n>>> nnnn://nnn.nnn.nnn/
nnnnn/nnnnnn-nnnnnnnnnnn\n>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn
nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn
nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nn
nnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, n
nnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn n
nnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn n
nnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnn
nnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnn
nnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn n
nnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnn
nnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnnnn nnn
nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>\n>> nnnn://nnn.nnn.nnn
/nnnnn/nnnnnn-nnnnnnnnnnn\n>>\n>>\n> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn n
nnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn
nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn
\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn
nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn
nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnn
nnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn
nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnn
nnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn n
n nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. N
nn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnn
nnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>\n> nnnn://nnn.n
nn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n\nNnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnn
nnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nn
nnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\,
nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn n
nn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn n
n nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnn
n nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn n
nnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnn
n (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn
nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn
nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN’n nnnnnn
nn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n\nnnnn://nnn.nnn.nn
n/nnnnn/nnnnnn-nnnnnnnnnnn\n
^ permalink raw reply [flat|nested] 76+ messages in thread* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-08-26 20:17 bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Peder O. Klingenberg @ 2016-08-27 3:35 ` npostavs 2016-08-30 13:09 ` Peder O. Klingenberg 2016-09-03 15:43 ` bug#24358: " npostavs 2016-10-18 8:16 ` bug#24358: 25.1.50; Sam Halliday 1 sibling, 2 replies; 76+ messages in thread From: npostavs @ 2016-08-27 3:35 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24315 peder@klingenberg.no (Peder O. Klingenberg) writes: > I recently started using gnus-icalendar to handle meeting invitations. > Someone sent me an invitation that included a rather long email thread > in typical outlook style, and gnus errored out when trying to display > the article. > > The backtrace showed that the error comes from the call > (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t) > in icalendar--read-element (nil nil). This looks like it would be an inefficient regexp, since it has nested stars. I suspect searching for "^[ \t]" multiple times would be more efficient than trying to match multiple lines in a single regexp. > > Strangely, the same recipe does not reproduce the error on os x, with a > build from master from 2016-08-12, but on my GNU/Linux machine, which is > where I run gnus and need this to work, it is 100% reproducible. I am > on Kubuntu 14.04.5, emacs is compiled with gcc (Ubuntu > 4.8.4-2ubuntu1~14.04.3) 4.8.4. > > Is this reproducible for anyone else, or do I need to dig deeper into my > environment? Any ideas on where to start digging? (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp matcher") and with 25.1-rc1 I get an assertion failure: character.h:703: Emacs fatal error: assertion failed: CHAR_VALID_P (ch) Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:354 354 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:354 #1 0x00000000005fa92d in die (msg=0x722518 "CHAR_VALID_P (ch)", file=0x72250c "character.h", line=703) at alloc.c:7223 #2 0x000000000056b841 in char_table_translate (obj=20656133, ch=4194341) at character.h:703 #3 0x00000000005e9d33 in re_match_2_internal (bufp=0xd68260 <searchbufs+32>, string1=0x1a9a970 " \202\245\001", size1=0, string2=0x1a9a970 " \202\245\001", size2=40918, pos=0, regs=0xd69e70 <search_regs>, stop=40918) at regex.c:5430 #4 0x00000000005e782c in re_search_2 (bufp=0xd68260 <searchbufs+32>, str1=0x1a9a970 " \202\245\001", size1=0, str2=0x1a9a970 " \202\245\001", size2=40918, startpos=0, range=40918, regs=0xd69e70 <search_regs>, stop=40918) at regex.c:4446 #5 0x00000000005d6447 in search_buffer (string=14974596, pos=1, pos_byte=1, lim=40891, lim_byte=40919, n=1, RE=1, trt=20656133, inverse_trt=20532565, posix=false) at search.c:1265 #6 0x00000000005d5be2 in search_command (string=14974596, bound=0, noerror=44448, count=0, direction=1, RE=1, posix=false) at search.c:1058 #7 0x00000000005d99a7 in Fre_search_forward (regexp=14974596, bound=0, noerror=44448, count=0) at search.c:2264 #8 0x000000000061cac3 in eval_sub (form=26022259) at eval.c:2176 #9 0x000000000061c124 in Feval (form=26022259, lexical=0) at eval.c:1988 #10 0x000000000061e052 in Ffuncall (nargs=3, args=0x7fffffffd678) at eval.c:2696 #11 0x0000000000668285 in exec_byte_code (bytestr=10946844, vector=10946877, maxdepth=30, args_template=2054, nargs=2, args=0x7fffffffdc90) at bytecode.c:880 #12 0x000000000061e958 in funcall_lambda (fun=10946789, nargs=2, arg_vector=0x7fffffffdc80) at eval.c:2855 #13 0x000000000061e2a1 in Ffuncall (nargs=3, args=0x7fffffffdc78) at eval.c:2742 #14 0x000000000061488d in Ffuncall_interactively (nargs=3, args=0x7fffffffdc78) at callint.c:252 #15 0x000000000061dee7 in Ffuncall (nargs=4, args=0x7fffffffdc70) at eval.c:2673 #16 0x000000000061d338 in Fapply (nargs=3, args=0x7fffffffdd50) at eval.c:2321 #17 0x0000000000614d93 in Fcall_interactively (function=4198576, record_flag=0, keys=14640533) at callint.c:389 #18 0x000000000061e08d in Ffuncall (nargs=4, args=0x7fffffffdfd8) at eval.c:2700 #19 0x0000000000668285 in exec_byte_code (bytestr=10951116, vector=10951149, maxdepth=54, args_template=4102, nargs=1, args=0x7fffffffe530) at bytecode.c:880 #20 0x000000000061e958 in funcall_lambda (fun=10951069, nargs=1, arg_vector=0x7fffffffe528) at eval.c:2855 #21 0x000000000061e2a1 in Ffuncall (nargs=2, args=0x7fffffffe520) at eval.c:2742 #22 0x000000000061d9e5 in call1 (fn=14784, arg1=4198576) at eval.c:2552 #23 0x00000000005734ce in command_loop_1 () at keyboard.c:1479 #24 0x000000000061a7c1 in internal_condition_case (bfun=0x572cb4 <command_loop_1>, handlers=19056, hfun=0x572346 <cmd_error>) at eval.c:1309 #25 0x00000000005728f6 in command_loop_2 (ignore=0) at keyboard.c:1107 #26 0x0000000000619d90 in internal_catch (tag=45840, func=0x5728cd <command_loop_2>, arg=0) at eval.c:1074 #27 0x0000000000572898 in command_loop () at keyboard.c:1086 #28 0x0000000000571e36 in recursive_edit_1 () at keyboard.c:692 #29 0x0000000000572036 in Frecursive_edit () at keyboard.c:763 #30 0x000000000056fde3 in main (argc=3, argv=0x7fffffffe9d8) at emacs.c:1626 Lisp Backtrace: "re-search-forward" (0xffffd470) "eval" (0xffffd680) "eval-expression" (0xffffdc80) "funcall-interactively" (0xffffdc78) "call-interactively" (0xffffdfe0) "command-execute" (0xffffe528) > > > > In GNU Emacs 25.1.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) > of 2016-08-11 built on luna > Repository revision: 36a57c55f2b855bca704c26bf7d787b7b471fe16 > Windowing system distributor 'The X.Org Foundation', version 11.0.11604000 > System Description: Ubuntu 14.04.5 LTS > > Recent messages: > scroll-down-command: Beginning of buffer [3 times] > (Shell command succeeded with no output) [91 times] > Back to top level > When done with this frame, type C-x 5 0 > Undo! [3 times] > calendar-event-problem.txt changed on disk; really edit the buffer? (y, n, r or C-h) r > ask-user-about-supersession-threat: File reverted: /home/pok/tmp/calendar-event-problem.txt > previous-line: Beginning of buffer [3 times] > Entering debugger... > Back to top level > > Configured using: > 'configure --prefix=/usr/local/emacs-git > --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/site-lisp/:/usr/share/emacs/site-lisp > --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars > --with-pop=yes' > > Configured features: > XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF > GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT > ZLIB TOOLKIT_SCROLL_BARS LUCID X11 > > Important settings: > value of $LC_MONETARY: en_US.UTF-8 > value of $LC_NUMERIC: en_US.UTF-8 > value of $LANG: en_US.UTF-8 > locale-coding-system: utf-8-unix > > Major mode: Text > > Minor modes in effect: > csv-field-index-mode: t > magit-auto-revert-mode: t > global-git-commit-mode: t > async-bytecomp-package-mode: t > shell-dirtrack-mode: t > diff-auto-refine-mode: t > show-paren-mode: t > yas-global-mode: t > yas-minor-mode: t > ido-everywhere: t > global-eldoc-mode: t > electric-indent-mode: t > mouse-wheel-mode: t > menu-bar-mode: t > file-name-shadow-mode: t > global-font-lock-mode: t > font-lock-mode: t > auto-composition-mode: t > auto-encryption-mode: t > auto-compression-mode: t > line-number-mode: t > auto-fill-function: do-auto-fill > transient-mark-mode: t > > Load-path shadows: > /home/pok/.emacs.d/elpa/org-20160822/org-macs hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-macs > /home/pok/.emacs.d/elpa/org-20160822/ob-dot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-dot > /home/pok/.emacs.d/elpa/org-20160822/ob-mscgen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-mscgen > /home/pok/.emacs.d/elpa/org-20160822/ob-clojure hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-clojure > /home/pok/.emacs.d/elpa/org-20160822/org-install hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-install > /home/pok/.emacs.d/elpa/org-20160822/org-faces hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-faces > /home/pok/.emacs.d/elpa/org-20160822/ob-scheme hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-scheme > /home/pok/.emacs.d/elpa/org-20160822/ob-haskell hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-haskell > /home/pok/.emacs.d/elpa/org-20160822/ob-sqlite hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sqlite > /home/pok/.emacs.d/elpa/org-20160822/ox-texinfo hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-texinfo > /home/pok/.emacs.d/elpa/org-20160822/ob-perl hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-perl > /home/pok/.emacs.d/elpa/org-20160822/ob-makefile hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-makefile > /home/pok/.emacs.d/elpa/org-20160822/ob-io hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-io > /home/pok/.emacs.d/elpa/org-20160822/org-docview hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-docview > /home/pok/.emacs.d/elpa/org-20160822/org-irc hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-irc > /home/pok/.emacs.d/elpa/org-20160822/ob-C hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-C > /home/pok/.emacs.d/elpa/org-20160822/ox-man hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-man > /home/pok/.emacs.d/elpa/org-20160822/org-capture hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-capture > /home/pok/.emacs.d/elpa/org-20160822/ob-table hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-table > /home/pok/.emacs.d/elpa/org-20160822/ob-sql hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sql > /home/pok/.emacs.d/elpa/org-20160822/org-list hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-list > /home/pok/.emacs.d/elpa/org-20160822/org-crypt hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-crypt > /home/pok/.emacs.d/elpa/org-20160822/org-attach hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-attach > /home/pok/.emacs.d/elpa/org-20160822/org-colview hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-colview > /home/pok/.emacs.d/elpa/org-20160822/org-id hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-id > /home/pok/.emacs.d/elpa/org-20160822/ob-plantuml hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-plantuml > /home/pok/.emacs.d/elpa/org-20160822/ox-publish hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-publish > /home/pok/.emacs.d/elpa/org-20160822/ob-tangle hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-tangle > /home/pok/.emacs.d/elpa/org-20160822/org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org > /home/pok/.emacs.d/elpa/org-20160822/org-indent hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-indent > /home/pok/.emacs.d/elpa/org-20160822/ox-ascii hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-ascii > /home/pok/.emacs.d/elpa/org-20160822/ob-matlab hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-matlab > /home/pok/.emacs.d/elpa/org-20160822/org-gnus hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-gnus > /home/pok/.emacs.d/elpa/org-20160822/org-feed hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-feed > /home/pok/.emacs.d/elpa/org-20160822/org-clock hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-clock > /home/pok/.emacs.d/elpa/org-20160822/org-element hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-element > /home/pok/.emacs.d/elpa/org-20160822/ob-screen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-screen > /home/pok/.emacs.d/elpa/org-20160822/ob hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob > /home/pok/.emacs.d/elpa/org-20160822/org-mobile hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mobile > /home/pok/.emacs.d/elpa/org-20160822/ox-latex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-latex > /home/pok/.emacs.d/elpa/org-20160822/ob-lisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lisp > /home/pok/.emacs.d/elpa/org-20160822/ob-calc hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-calc > /home/pok/.emacs.d/elpa/org-20160822/org-bibtex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-bibtex > /home/pok/.emacs.d/elpa/org-20160822/org-macro hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-macro > /home/pok/.emacs.d/elpa/org-20160822/org-agenda hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-agenda > /home/pok/.emacs.d/elpa/org-20160822/org-entities hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-entities > /home/pok/.emacs.d/elpa/org-20160822/ob-css hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-css > /home/pok/.emacs.d/elpa/org-20160822/ob-R hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-R > /home/pok/.emacs.d/elpa/org-20160822/org-mouse hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mouse > /home/pok/.emacs.d/elpa/org-20160822/org-timer hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-timer > /home/pok/.emacs.d/elpa/org-20160822/ob-java hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-java > /home/pok/.emacs.d/elpa/org-20160822/ob-gnuplot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-gnuplot > /home/pok/.emacs.d/elpa/org-20160822/ob-keys hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-keys > /home/pok/.emacs.d/elpa/org-20160822/ob-python hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-python > /home/pok/.emacs.d/elpa/org-20160822/org-compat hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-compat > /home/pok/.emacs.d/elpa/org-20160822/ob-fortran hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-fortran > /home/pok/.emacs.d/elpa/org-20160822/ob-exp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-exp > /home/pok/.emacs.d/elpa/org-20160822/ox-html hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-html > /home/pok/.emacs.d/elpa/org-20160822/ob-comint hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-comint > /home/pok/.emacs.d/elpa/org-20160822/org-src hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-src > /home/pok/.emacs.d/elpa/org-20160822/ob-scala hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-scala > /home/pok/.emacs.d/elpa/org-20160822/org-version hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-version > /home/pok/.emacs.d/elpa/org-20160822/org-loaddefs hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-loaddefs > /home/pok/.emacs.d/elpa/org-20160822/ob-emacs-lisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-emacs-lisp > /home/pok/.emacs.d/elpa/org-20160822/org-datetree hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-datetree > /home/pok/.emacs.d/elpa/org-20160822/ob-asymptote hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-asymptote > /home/pok/.emacs.d/elpa/org-20160822/ox-org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-org > /home/pok/.emacs.d/elpa/org-20160822/org-habit hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-habit > /home/pok/.emacs.d/elpa/org-20160822/ox hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox > /home/pok/.emacs.d/elpa/org-20160822/org-w3m hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-w3m > /home/pok/.emacs.d/elpa/org-20160822/ob-lob hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lob > /home/pok/.emacs.d/elpa/org-20160822/org-protocol hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-protocol > /home/pok/.emacs.d/elpa/org-20160822/ob-shen hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-shen > /home/pok/.emacs.d/elpa/org-20160822/ob-maxima hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-maxima > /home/pok/.emacs.d/elpa/org-20160822/ob-ref hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ref > /home/pok/.emacs.d/elpa/org-20160822/ob-org hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-org > /home/pok/.emacs.d/elpa/org-20160822/ob-latex hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-latex > /home/pok/.emacs.d/elpa/org-20160822/ox-md hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-md > /home/pok/.emacs.d/elpa/org-20160822/org-mhe hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-mhe > /home/pok/.emacs.d/elpa/org-20160822/ob-ledger hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ledger > /home/pok/.emacs.d/elpa/org-20160822/org-archive hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-archive > /home/pok/.emacs.d/elpa/org-20160822/org-ctags hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-ctags > /home/pok/.emacs.d/elpa/org-20160822/org-info hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-info > /home/pok/.emacs.d/elpa/org-20160822/ob-octave hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-octave > /home/pok/.emacs.d/elpa/org-20160822/org-pcomplete hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-pcomplete > /home/pok/.emacs.d/elpa/org-20160822/ob-ditaa hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ditaa > /home/pok/.emacs.d/elpa/org-20160822/org-plot hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-plot > /home/pok/.emacs.d/elpa/org-20160822/ob-eval hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-eval > /home/pok/.emacs.d/elpa/org-20160822/org-table hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-table > /home/pok/.emacs.d/elpa/org-20160822/ox-beamer hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-beamer > /home/pok/.emacs.d/elpa/org-20160822/ox-odt hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-odt > /home/pok/.emacs.d/elpa/org-20160822/ob-core hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-core > /home/pok/.emacs.d/elpa/org-20160822/org-inlinetask hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-inlinetask > /home/pok/.emacs.d/elpa/org-20160822/org-rmail hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-rmail > /home/pok/.emacs.d/elpa/org-20160822/ox-icalendar hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ox-icalendar > /home/pok/.emacs.d/elpa/org-20160822/ob-lilypond hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-lilypond > /home/pok/.emacs.d/elpa/org-20160822/ob-picolisp hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-picolisp > /home/pok/.emacs.d/elpa/org-20160822/ob-sass hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-sass > /home/pok/.emacs.d/elpa/org-20160822/org-eshell hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-eshell > /home/pok/.emacs.d/elpa/org-20160822/ob-awk hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-awk > /home/pok/.emacs.d/elpa/org-20160822/ob-ruby hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ruby > /home/pok/.emacs.d/elpa/org-20160822/ob-ocaml hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-ocaml > /home/pok/.emacs.d/elpa/org-20160822/ob-js hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/ob-js > /home/pok/.emacs.d/elpa/org-20160822/org-footnote hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-footnote > /home/pok/.emacs.d/elpa/org-20160822/org-bbdb hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/org/org-bbdb > /usr/share/emacs24/site-lisp/latex-cjk-thai/thai-word hides /usr/local/emacs-git/share/emacs/25.1.50/lisp/language/thai-word > > Features: > (shadow emacsbug gnus-dup gnus-draft nndoc cus-edit ess-omg-l > ess-toolbar ess-mouse mouseme ess-menu ess-swv ess-noweb essd-els > ess-sas-d ess-sas-l ess-sas-a ess-sta-d ess-sta-l make-regexp ess-sp6-d > ess-dde ess-sp3-d ess-julia julia-mode ess-r-d ess-r-syntax > ess-r-completion ess-roxy essddr hideshow ess-help reporter > ess-r-package ess-s-l ess-site ess ess-inf ess-tracebug ess-mode > ess-noweb-mode ess-custom executable ess-generics ess-utils ess-bugs-l > ess-compat ess-lsp-l map esh-var esh-io esh-cmd esh-opt esh-ext esh-proc > esh-arg esh-groups eshell esh-module esh-mode esh-util dired-x autoload > tar-mode ffap php-mode flymake cc-mode cc-fonts cc-guess cc-menus > cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs hippie-exp vc > vc-dispatcher url-queue grep pulse vc-cvs slime-indentation > slime-cl-indent cl-indent slime-fancy slime-trace-dialog > slime-fontifying-fu slime-package-fu slime-references > slime-compiler-notes-tree slime-scratch slime-presentations bridge > slime-macrostep macrostep slime-mdot-fu slime-enclosing-context > slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c > slime-editing-commands slime-autodoc slime-repl elp slime-parse slime > lisp-mnt gud apropos etags xref project arc-mode archive-mode hyperspec > csv-mode magit-blame magit-stash magit-bisect magit-remote magit-commit > magit-sequence magit magit-apply magit-wip magit-log magit-diff > smerge-mode magit-core magit-autorevert autorevert filenotify > magit-process magit-popup magit-mode magit-git magit-section magit-utils > git-commit log-edit pcvs-util with-editor async-bytecomp async tramp-sh > tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell dash > eieio-opt speedbar sb-image ezimage dframe cal-china lunar solar cal-dst > cal-bahai cal-islam cal-hebrew holidays hol-loaddefs cal-iso bookmark pp > tabify org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view > jka-compr image-mode org-bbdb org-w3m org-table org-archive org-clock > org-indent ob-ditaa ob-plantuml org-bibtex org-element avl-tree bibtex > org-colview org-crypt org-habit org-agenda help-fns radix-tree misearch > multi-isearch thingatpt debbugs-gnu add-log debbugs soap-client warnings > rng-xsd rng-dt rng-util xsd-regexp debug cus-start cus-load mailalias > bbdb-message footnote ecomplete flow-fill vc-git diff-mode sort > gnus-cite shr-color color shr svg dom browse-url mail-extr gnus-async > gnus-bcklg qp gnus-ml disp-table gnus-topic mm-archive url-http url-gw > url-cache url-auth pop3 nnrss xml mm-url url url-proxy url-privacy > url-expand url-methods url-history url-cookie url-domsuf url-util > nndraft nnmh nnml utf-7 bbdb-gnus epa-file network-stream nsm starttls > gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp > gnus-cache pok-gnus gnus-icalendar org-capture gnus-art mm-uu mml2015 > mm-view mml-smime smime dig mailcap icalendar diary-lib diary-loaddefs > nnir gnus-sum gnus-group gnus-undo bbdb-mua bbdb-com crm bbdb bbdb-site > timezone gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 > netrc nnoo parse-time gnus-spec gnus-int gnus-range message sendmail > puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg mm-decode > mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader > gnus-win gnus nnheader subr-x gnus-util rmail rmail-loaddefs rfc2047 > rfc2045 ietf-drums mail-utils wid-edit linum paren paredit pok-init > bugz-mode yasnippet org advice org-macro org-footnote org-pcomplete > pcomplete org-list org-faces org-entities time-date noutline outline > org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp > org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs > org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs gedcom > slime-autoloads reftex reftex-loaddefs reftex-vars edmacro kmacro ido > server filladapt dmacro mm-util mail-prsvr cl compile comint ansi-color > ring finder-inf tex-site info package epg-config url-handlers url-parse > auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs > password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra > help-mode easymenu cconv cl-loaddefs pcase cl-lib emacs-goodies-el > emacs-goodies-custom emacs-goodies-loaddefs easy-mmode mule-util tooltip > eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel > term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image > regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode > prog-mode register page menu-bar rfn-eshadow timer select scroll-bar > mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame > cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai > tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian > slovak czech european ethiopic indian cyrillic chinese charscript > case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer > cl-preloaded nadvice loaddefs button faces cus-face macroexp files > text-properties overlay sha1 md5 base64 format env code-pages mule > custom widget hashtable-print-readable backquote dbusbind inotify > dynamic-setting system-font-setting font-render-setting x-toolkit x > multi-tty make-network-process emacs) > > Memory information: > ((conses 16 2485829 182861) > (symbols 48 72236 91) > (miscs 40 3269 4672) > (strings 32 298119 63000) > (string-bytes 1 12887713) > (vectors 16 103720) > (vector-slots 8 2448384 49706) > (floats 8 4985 2034) > (intervals 56 225770 627) > (buffers 976 190) > (heap 1024 299121 -1842968)) ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-08-27 3:35 ` npostavs @ 2016-08-30 13:09 ` Peder O. Klingenberg 2016-09-02 1:58 ` npostavs 2016-09-03 15:43 ` bug#24358: " npostavs 1 sibling, 1 reply; 76+ messages in thread From: Peder O. Klingenberg @ 2016-08-30 13:09 UTC (permalink / raw) To: npostavs; +Cc: 24315 [-- Attachment #1: Type: text/plain, Size: 1409 bytes --] On Fri, Aug 26 2016 at 23:35, npostavs@users.sourceforge.net wrote: > This looks like it would be an inefficient regexp, since it has nested > stars. I suspect searching for "^[ \t]" multiple times would be more > efficient than trying to match multiple lines in a single regexp. Tried that. It sort of worked, in that it worked when I directly called `icalendar--read-event' in a buffer containing the event as manually extracted from the gnus message. However, parsing the problematic message in gnus still failed. It turns out `gnus-icalendar-event-from-buffer' calls `icalendar--get-unfolded-buffer' before `icalendar--read-event'. `icalendar--get-unfolded-buffer' takes care of all those pesky line continuations, and returns a buffer with each element occupying exactly one line. So essentially `icalendar--read-event' was using a regexp to extract the rest of the line, and that failed with a line nearly 40k characters long. The only other in-tree caller of `icalendar--read-event' (excluding itself) also calls `icalendar--get-unfolded-buffer' first, and indeed, `icalendar-read-event' already relies on this to take care of line continuations in element parameters (as opposed to values). Attached is a patch that uses buffer-substring to accomplish the same thing as the offending regexp, and documents the dependency on `icalendar--get-unfolded-buffer'. This fixes the problem for me. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: bug24315.patch --] [-- Type: text/x-diff, Size: 1540 bytes --] From c3ae84dc48a993bb1906d5c9b6b663184e2a9d9d Mon Sep 17 00:00:00 2001 From: "Peder O. Klingenberg" <peder@klingenberg.no> Date: Tue, 30 Aug 2016 14:44:16 +0200 Subject: [PATCH] Avoid crash in icalendar--read-element * lisp/calendar/icalendar.el (icalendar--read-element): Stop crashing when parsing overly long event descriptions. (Bug#24315) --- lisp/calendar/icalendar.el | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/calendar/icalendar.el b/lisp/calendar/icalendar.el index 386c554..19930d5 100644 --- a/lisp/calendar/icalendar.el +++ b/lisp/calendar/icalendar.el @@ -361,7 +361,8 @@ icalendar--read-element INVALUE gives the current iCalendar element we are reading. INPARAMS gives the current parameters..... This function calls itself recursively for each nested calendar element -it finds." +it finds. The current buffer should be an unfolded buffer as returned +from `icalendar--get-unfolded-buffer'." (let (element children line name params param param-name param-value value (continue t)) @@ -391,8 +392,8 @@ icalendar--read-element (unless (looking-at ":") (error "Oops")) (forward-char 1) - (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t) - (setq value (icalendar--rris "\r?\n[ \t]" "" (match-string 0))) + (setq value (buffer-substring (point) (line-end-position))) + (end-of-line) (setq line (list name params value)) (cond ((eq name 'BEGIN) (setq children -- 2.9.3 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-08-30 13:09 ` Peder O. Klingenberg @ 2016-09-02 1:58 ` npostavs 2016-09-02 13:45 ` Peder O. Klingenberg 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-09-02 1:58 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24315 pok@netfonds.no (Peder O. Klingenberg) writes: > `icalendar--get-unfolded-buffer' takes care of all those pesky line > continuations, and returns a buffer with each element occupying exactly > one line. So essentially `icalendar--read-event' was using a regexp to > extract the rest of the line, and that failed with a line nearly 40k > characters long. > > The only other in-tree caller of `icalendar--read-event' (excluding > itself) also calls `icalendar--get-unfolded-buffer' first, and indeed, > `icalendar-read-event' already relies on this to take care of line > continuations in element parameters (as opposed to values). > > Attached is a patch that uses buffer-substring to accomplish the same > thing as the offending regexp, and documents the dependency on > `icalendar--get-unfolded-buffer'. This fixes the problem for me. If it works without the regexp, that's even better. > -it finds." > +it finds. The current buffer should be an unfolded buffer as returned ^ Sentences should be double spaced. > +from `icalendar--get-unfolded-buffer'." > (let (element children line name params param param-name param-value > value > (continue t)) > @@ -391,8 +392,8 @@ icalendar--read-element > (unless (looking-at ":") > (error "Oops")) > (forward-char 1) > - (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t) > - (setq value (icalendar--rris "\r?\n[ \t]" "" (match-string 0))) > + (setq value (buffer-substring (point) (line-end-position))) > + (end-of-line) Might be better to avoid finding the end of line twice (since apparently 40k lines do happen, I guess it's worth thinking a bit about optimizing): (let ((start (prog1 (point) (end-of-line)))) (setq value (buffer-substring start (point)))) ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-09-02 1:58 ` npostavs @ 2016-09-02 13:45 ` Peder O. Klingenberg 2016-09-03 14:21 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Peder O. Klingenberg @ 2016-09-02 13:45 UTC (permalink / raw) To: 24315 [-- Attachment #1: Type: text/plain, Size: 757 bytes --] On Thu, Sep 01 2016 at 21:58, npostavs@users.sourceforge.net wrote: >> -it finds." >> +it finds. The current buffer should be an unfolded buffer as returned > ^ > Sentences should be double spaced. Gah! And I'm usually chided for using old-fashioned double spaces in prose. :) > Might be better to avoid finding the end of line twice (since apparently > 40k lines do happen, I guess it's worth thinking a bit about > optimizing): Even finding the the end of the line twice was faster than the regexp method, subjectively. On my problematic 40k line, it did not take noticable time, whereas the regexp caused a bit of a delay even on shorter events. But I agree, let's not make emacs do more work than necessary. Updated patch attached. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: bug24315.patch --] [-- Type: text/x-diff, Size: 1563 bytes --] From b51d09286492ae9be32b3718407174236db54059 Mon Sep 17 00:00:00 2001 From: "Peder O. Klingenberg" <peder@klingenberg.no> Date: Tue, 30 Aug 2016 14:44:16 +0200 Subject: [PATCH] Avoid crash in icalendar--read-element * lisp/calendar/icalendar.el (icalendar--read-element): Stop crashing when parsing overly long event descriptions. (Bug#24315) --- lisp/calendar/icalendar.el | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/calendar/icalendar.el b/lisp/calendar/icalendar.el index 386c554..c88f4ab 100644 --- a/lisp/calendar/icalendar.el +++ b/lisp/calendar/icalendar.el @@ -361,7 +361,8 @@ icalendar--read-element INVALUE gives the current iCalendar element we are reading. INPARAMS gives the current parameters..... This function calls itself recursively for each nested calendar element -it finds." +it finds. The current buffer should be an unfolded buffer as returned +from `icalendar--get-unfolded-buffer'." (let (element children line name params param param-name param-value value (continue t)) @@ -391,8 +392,9 @@ icalendar--read-element (unless (looking-at ":") (error "Oops")) (forward-char 1) - (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t) - (setq value (icalendar--rris "\r?\n[ \t]" "" (match-string 0))) + (let ((start (point))) + (end-of-line) + (setq value (buffer-substring start (point)))) (setq line (list name params value)) (cond ((eq name 'BEGIN) (setq children -- 2.9.3 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-09-02 13:45 ` Peder O. Klingenberg @ 2016-09-03 14:21 ` npostavs 2016-09-06 8:18 ` Peder O. Klingenberg 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-09-03 14:21 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24315 # the new bug will be about the specdl error clone 24315 -1 # this bug is about the bad regex in icalendar retitle 24315 icalendar--read-element uses inefficient regexp quit peder@klingenberg.no (Peder O. Klingenberg) writes: > Updated patch attached. > [...] > Subject: [PATCH] Avoid crash in icalendar--read-element > > * lisp/calendar/icalendar.el (icalendar--read-element): Stop crashing > when parsing overly long event descriptions. (Bug#24315) Patch looks good, though I think the description shouldn't say "crash", since the problem is a regex stack overflow, which is just a normal Emacs error (I've figured out the reason why it's triggering max-specpdl-size instead of regex stack overflow in master, and will address it in a separate bug). ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-09-03 14:21 ` npostavs @ 2016-09-06 8:18 ` Peder O. Klingenberg 2016-09-07 23:27 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Peder O. Klingenberg @ 2016-09-06 8:18 UTC (permalink / raw) To: npostavs; +Cc: 24315 [-- Attachment #1: Type: text/plain, Size: 288 bytes --] On Sat, Sep 03 2016 at 10:21, npostavs@users.sourceforge.net wrote: > Patch looks good, though I think the description shouldn't say "crash", > since the problem is a regex stack overflow, which is just a normal > Emacs error I agree, that was a poor choice of words. How about this? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: bug24315.patch --] [-- Type: text/x-diff, Size: 1591 bytes --] From bd28797ce52c070e59d26483bdf842fd31651de6 Mon Sep 17 00:00:00 2001 From: "Peder O. Klingenberg" <peder@klingenberg.no> Date: Tue, 30 Aug 2016 14:44:16 +0200 Subject: [PATCH] Avoid error in icalendar--read-element * lisp/calendar/icalendar.el (icalendar--read-element): Avoid a regex stack overflow by not using regex to extract values from calendar events. (Bug#24315) --- lisp/calendar/icalendar.el | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/calendar/icalendar.el b/lisp/calendar/icalendar.el index 386c554..c88f4ab 100644 --- a/lisp/calendar/icalendar.el +++ b/lisp/calendar/icalendar.el @@ -361,7 +361,8 @@ icalendar--read-element INVALUE gives the current iCalendar element we are reading. INPARAMS gives the current parameters..... This function calls itself recursively for each nested calendar element -it finds." +it finds. The current buffer should be an unfolded buffer as returned +from `icalendar--get-unfolded-buffer'." (let (element children line name params param param-name param-value value (continue t)) @@ -391,8 +392,9 @@ icalendar--read-element (unless (looking-at ":") (error "Oops")) (forward-char 1) - (re-search-forward "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t) - (setq value (icalendar--rris "\r?\n[ \t]" "" (match-string 0))) + (let ((start (point))) + (end-of-line) + (setq value (buffer-substring start (point)))) (setq line (list name params value)) (cond ((eq name 'BEGIN) (setq children -- 2.9.3 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-09-06 8:18 ` Peder O. Klingenberg @ 2016-09-07 23:27 ` npostavs 0 siblings, 0 replies; 76+ messages in thread From: npostavs @ 2016-09-07 23:27 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24315 tags 24315 fixed close 24315 25.2 quit peder@klingenberg.no (Peder O. Klingenberg) writes: > On Sat, Sep 03 2016 at 10:21, npostavs@users.sourceforge.net wrote: > > I agree, that was a poor choice of words. How about this? Thanks, pushed as 55dde6c1 ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-08-27 3:35 ` npostavs 2016-08-30 13:09 ` Peder O. Klingenberg @ 2016-09-03 15:43 ` npostavs 2016-10-08 0:29 ` npostavs 1 sibling, 1 reply; 76+ messages in thread From: npostavs @ 2016-09-03 15:43 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24358 # this cloned bug doesn't have a patch yet tags 24358 - patch quit npostavs@users.sourceforge.net writes: > (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with > 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp > matcher") The problem is that re_max_failures is set to 40001 (instead of the original 40000) in main()[1], which is a problem because of the GROW_FAIL_STACK uses (re_max_failures * TYPICAL_FAILURE_SIZE) as a cap on the amount to allocate, but ((fail_stack).size * sizeof (fail_stack_elt_t)) to calculate current allocation. Since TYPICAL_FAILURE_SIZE = 20 and sizeof (fail_stack_elt_t) = 8, and it seems that (fail_stack).size grows in increments of 3, when (fail_stack).avail is 99999 and (fail_stack).size reaches 100002: (fail_stack).size * sizeof (fail_stack_elt_t) => 800016 re_max_failures * TYPICAL_FAILURE_SIZE => 800020 ENSURE_FAIL_STACK(3) then loops indefinitely reallocating a stack of size 800020 again and again until the record_xmalloc fails to grow_specdl() (thus the "max-specpdl-size" error). ---------- So we we might want to fix the re_max_failures setting in main, but it doesn't quite make sense to me that GROW_FAIL_STACK relies on re_max_failures being a multiple of (sizeof (fail_stack_elt_t)). At the definition of TYPICAL_FAILURE_SIZE we have /* Estimate the size of data pushed by a typical failure stack entry. An estimate is all we need, because all we use this for is to choose a limit for how big to make the failure stack. */ /* BEWARE, the value `20' is hard-coded in emacs.c:main(). */ #define TYPICAL_FAILURE_SIZE 20 Why do we use an "estimate" here? What's wrong with just using (re_max_failures * sizeof (fail_stack_elt_t)) as the limit? Or should the limit actually be (re_max_failures * TYPICAL_FAILURE_SIZE * sizeof (fail_stack_elt_t))? ----------- 827 long lim = rlim.rlim_cur; (gdb) p rlim $1 = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } (gdb) next 833 int ratio = 20 * sizeof (char *); (gdb) 834 ratio += ratio / 3; (gdb) 837 int extra = 200000; (gdb) p ratio $2 = 213 [...] (gdb) display ((newlim - extra) / ratio) 1: ((newlim - extra) / ratio) = 40000 (gdb) next 856 newlim += pagesize - 1; 1: ((newlim - extra) / ratio) = 40000 (gdb) 857 if (0 <= rlim.rlim_max && rlim.rlim_max < newlim) 1: ((newlim - extra) / ratio) = 40019 (gdb) 859 newlim -= newlim % pagesize; 1: ((newlim - extra) / ratio) = 40019 (gdb) 861 if (pagesize <= newlim - lim) 1: ((newlim - extra) / ratio) = 40001 (gdb) undisplay 1 (gdb) next 863 rlim.rlim_cur = newlim; (gdb) 864 if (setrlimit (RLIMIT_STACK, &rlim) == 0) (gdb) 865 lim = newlim; (gdb) 870 re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; (gdb) 875 stack_bottom = &stack_bottom_variable; (gdb) p re_max_failures $3 = 40001 ----------- [1]: This was the case since 9d356f62 2016-05-27 "Robustify stack-size calculation" ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-09-03 15:43 ` bug#24358: " npostavs @ 2016-10-08 0:29 ` npostavs 2016-10-08 5:55 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-08 0:29 UTC (permalink / raw) To: Peder O. Klingenberg; +Cc: 24358 npostavs@users.sourceforge.net writes: > >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp >> matcher") icalendar--read-element has been fixed, but this still reproduces when doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given in the OP. And I'm still seeing an assertion failure due to what looks like memory corruption on the emacs-25 branch. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 0:29 ` npostavs @ 2016-10-08 5:55 ` Eli Zaretskii 2016-10-08 13:45 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-08 5:55 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Date: Fri, 07 Oct 2016 20:29:36 -0400 > Cc: 24358@debbugs.gnu.org > > npostavs@users.sourceforge.net writes: > > > >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with > >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp > >> matcher") > > icalendar--read-element has been fixed, but this still reproduces when > doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given > in the OP. Isn't that "user error"? > And I'm still seeing an assertion failure due to what looks like > memory corruption on the emacs-25 branch. Details of the assertion? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 5:55 ` Eli Zaretskii @ 2016-10-08 13:45 ` npostavs 2016-10-08 14:39 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-08 13:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder [-- Attachment #1: Type: text/plain, Size: 2720 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Date: Fri, 07 Oct 2016 20:29:36 -0400 >> Cc: 24358@debbugs.gnu.org >> >> npostavs@users.sourceforge.net writes: >> > >> >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with >> >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp >> >> matcher") >> >> icalendar--read-element has been fixed, but this still reproduces when >> doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given >> in the OP. > > Isn't that "user error"? Yes, but it should give "Stack overflow in regexp matcher", not overflow the lisp stack (or assertion failure). > >> And I'm still seeing an assertion failure due to what looks like >> memory corruption on the emacs-25 branch. > > Details of the assertion? (See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#8) I tracked the corruption to a malloc call, but I wasn't able to figure out what's happening there. I used the following to debug: Apply the attached bug-24358-hunting.diff and then run gdb --args ./emacs -Q -batch -l ~/src/emacs/bug-24358-regex-max-specpdl.el Where ~/src/emacs/bug-24358-regex-max-specpdl.el is: (with-temp-buffer (insert-file-contents "~/src/emacs/bug-24358-regex-max-specpdl.txt") ; adjust path (goto-char (point-min)) (re-search-forward ".*\\(\n.*\\)*" nil t)) I show some more excerpts in the attached bug-24358-debug.log, but my main finding is that string1 of re_match_2_internal is originally: string1=0x1835980 "DESCRIPTION;LANGUAGE= but then it becomes corrupted during a malloc: Old value = 68 'D' New value = 0 '\000' 0x00007ffff0cc01a7 in __memset_sse2_unaligned_erms () from /usr/lib/libc.so.6 (gdb) bt 13 #0 0x00007ffff0cc01a7 in __memset_sse2_unaligned_erms () from /usr/lib/libc.so.6 #1 0x00000000006d27f5 in r_alloc_sbrk (size=290816) at ralloc.c:848 #2 0x00000000006ced96 in get_contiguous_space (size=290816, position=0x1833000) at gmalloc.c:476 #3 0x00000000006cf92a in _malloc_internal_nolock (size=163840) at gmalloc.c:844 #4 0x00000000006cfe9d in _malloc_internal (size=163840) at gmalloc.c:927 #5 0x00000000006cff1a in gmalloc (size=163840) at gmalloc.c:951 #6 0x00000000006d14e4 in malloc (size=163840) at gmalloc.c:1827 #7 0x00000000005f3e6b in lmalloc (size=163840) at alloc.c:1414 #8 0x00000000005f3356 in xmalloc (size=163840) at alloc.c:821 #9 0x00000000005f38e4 in record_xmalloc (size=163840) at alloc.c:1038 #10 0x00000000005ee233 in re_match_2_internal (bufp=0xd6d650 <searchbufs+5072>, string1=0x1835980 "", size1=0, string2=0x1835980 "", size2=40918, pos=0, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:5844 [-- Attachment #2: changes to hunt down bug 24358 --] [-- Type: text/plain, Size: 3199 bytes --] diff --git i/src/.gdbinit w/src/.gdbinit index a4e9f70..d17d1ba 100644 --- i/src/.gdbinit +++ w/src/.gdbinit @@ -1280,3 +1280,22 @@ commands end continue end + +# bug 24315 +break re_match_2_internal if (size2>2000 && size2==stop) +commands + p debug = 1 + continue +end +break debug_spot +commands + watch -l string1[0] + disable 4 + # cond 4 (string1[0] != 'D') + # continue +end +# break debug_malloc if ((mem <= 0x1834980) && (0x1834980 < mem + size)) + + + + diff --git i/src/gmalloc.c w/src/gmalloc.c index 00b8364..5084609 100644 --- i/src/gmalloc.c +++ w/src/gmalloc.c @@ -914,6 +914,10 @@ _malloc_internal_nolock (size_t size) return result; } +void debug_malloc (void* mem, size_t size) +{ +} + void * _malloc_internal (size_t size) { @@ -923,6 +927,7 @@ _malloc_internal (size_t size) result = _malloc_internal_nolock (size); UNLOCK (); + debug_malloc (result, size); return result; } diff --git i/src/regex.c w/src/regex.c index 164eb46..861b800 100644 --- i/src/regex.c +++ w/src/regex.c @@ -828,6 +828,7 @@ extract_number_and_incr (re_char **source) interactively. And if linked with the main program in `main.c' and the other test files, you can run the already-written tests. */ +#define DEBUG #ifdef DEBUG /* We use standard I/O for debugging. */ @@ -838,6 +839,13 @@ extract_number_and_incr (re_char **source) static int debug = -100000; +static void debug_spot (int fail_stack_avail, const char*string1, const char*string2) +{ + extern void r_alloc_check (void); + //r_alloc_check (); + fail_stack_avail++; +} + # define DEBUG_STATEMENT(e) e # define DEBUG_PRINT(...) if (debug > 0) printf (__VA_ARGS__) # define DEBUG_COMPILES_ARGUMENTS @@ -1172,16 +1180,31 @@ print_double_string (re_char *where, re_char *string1, ssize_t size1, printf ("(null)"); else { + int i; if (FIRST_STRING_P (where)) { - for (this_char = where - string1; this_char < size1; this_char++) - putchar (string1[this_char]); + for (i = 0, this_char = where - string1; this_char < size1; i++, this_char++) + { + if (i > 20) + { + putchar ('.'); putchar ('.'); putchar ('.'); + break; + } + putchar (string1[this_char]); + } where = string2; } - for (this_char = where - string2; this_char < size2; this_char++) - putchar (string2[this_char]); + for (i = 0, this_char = where - string2; this_char < size2; i++, this_char++) + { + if (i > 20) + { + putchar ('.'); putchar ('.'); putchar ('.'); + break; + } + putchar (string2[this_char]); + } } } @@ -1533,6 +1556,7 @@ while (REMAINING_AVAIL_SLOTS <= space) { \ of 0 + -1 isn't done as unsigned. */ \ \ DEBUG_STATEMENT (nfailure_points_pushed++); \ + if (debug > 0) debug_spot((fail_stack).avail, string1,string2); \ DEBUG_PRINT ("\nPUSH_FAILURE_POINT:\n"); \ DEBUG_PRINT (" Before push, next avail: %zd\n", (fail_stack).avail); \ DEBUG_PRINT (" size: %zd\n", (fail_stack).size);\ [-- Attachment #3: gdb session excerpts --] [-- Type: text/plain, Size: 7321 bytes --] The compiled pattern is: The string to match is: "DESCRIPTION;LANGUAGE=..." 0x144aa80: EXECUTING on_failure_jump_smart 4 (to 0x144aa87). smart default => slow loop. 0x144aa80: EXECUTING on_failure_jump 4 (to 0x144aa87): Thread 1 "emacs" hit Breakpoint 4, debug_spot (fail_stack_avail=0, string1=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., string2=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "...) at regex.c:846 846 fail_stack_avail++; Hardware watchpoint 5: -location string1[0] (gdb) bt 5 #0 debug_spot (fail_stack_avail=0, string1=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., string2=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "...) at regex.c:846 #1 0x00000000005ee090 in re_match_2_internal (bufp=0xd6d650 <searchbufs+5072>, string1=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size1=0, string2=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size2=40918, pos=0, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:5844 #2 0x00000000005e9022 in re_search_2 (bufp=0xd6d650 <searchbufs+5072>, str1=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size1=0, str2=0x1835980 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size2=40918, startpos=0, range=40918, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:4470 #3 0x00000000005d6c06 in search_buffer (string=25301860, pos=1, pos_byte=1, lim=40891, lim_byte=40919, n=1, RE=1, trt=20893029, inverse_trt=20483397, posix=false) at search.c:1265 #4 0x00000000005d63a1 in search_command (string=25301860, bound=0, noerror=44544, count=0, direction=1, RE=1, posix=false) at search.c:1058 (More stack frames follow...) (gdb) cont [...] PUSH_FAILURE_POINT: Before push, next avail: 5115 size: 5120 Push frame index: 5115 Push string 0x1836013: ".nnn>\;\n> +NNNN <NNN..." 0: /on_failure_jump to 7 3: /anychar 4: /jump to 0 7: /stop_memory/1 9: /jump to -8 12: /succeed 13: end of pattern. Push pattern 0x144aa8f: 0x144aa92: EXECUTING anychar. Matched "46". 0x144aa93: EXECUTING jump -7 (to 0x144aa8f). 0x144aa8f: EXECUTING on_failure_jump 4 (to 0x144aa96): PUSH_FAILURE_POINT: Before push, next avail: 5118 size: 5120 Thread 1 "emacs" hit Hardware watchpoint 5: -location string1[0] Old value = 68 'D' New value = 0 '\000' 0x00007ffff0cc01a7 in __memset_sse2_unaligned_erms () from /usr/lib/libc.so.6 (gdb) bt 13 #0 0x00007ffff0cc01a7 in __memset_sse2_unaligned_erms () from /usr/lib/libc.so.6 #1 0x00000000006d27f5 in r_alloc_sbrk (size=290816) at ralloc.c:848 #2 0x00000000006ced96 in get_contiguous_space (size=290816, position=0x1833000) at gmalloc.c:476 #3 0x00000000006cf92a in _malloc_internal_nolock (size=163840) at gmalloc.c:844 #4 0x00000000006cfe9d in _malloc_internal (size=163840) at gmalloc.c:927 #5 0x00000000006cff1a in gmalloc (size=163840) at gmalloc.c:951 #6 0x00000000006d14e4 in malloc (size=163840) at gmalloc.c:1827 #7 0x00000000005f3e6b in lmalloc (size=163840) at alloc.c:1414 #8 0x00000000005f3356 in xmalloc (size=163840) at alloc.c:821 #9 0x00000000005f38e4 in record_xmalloc (size=163840) at alloc.c:1038 #10 0x00000000005ee233 in re_match_2_internal (bufp=0xd6d650 <searchbufs+5072>, string1=0x1835980 "", size1=0, string2=0x1835980 "", size2=40918, pos=0, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:5844 #11 0x00000000005e9022 in re_search_2 (bufp=0xd6d650 <searchbufs+5072>, str1=0x1835980 "", size1=0, str2=0x1835980 "", size2=40918, startpos=0, range=40918, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:4470 #12 0x00000000005d6c06 in search_buffer (string=25301860, pos=1, pos_byte=1, lim=40891, lim_byte=40919, n=1, RE=1, trt=20893029, inverse_trt=20483397, posix=false) at search.c:1265 (More stack frames follow...) Continuing. Thread 1 "emacs" hit Hardware watchpoint 5: -location string1[0] Old value = 0 '\000' New value = -34 '\336' 0x00007ffff0d67b64 in __memcpy_ssse3 () from /usr/lib/libc.so.6 (gdb) cont Continuing. Doubled stack; size now: 20480 slots available: 15362 Push frame index: 5118 Push string 0x1836014: "ª$..." [...] PUSH_FAILURE_POINT: Before push, next avail: 5130 size: 20480 Push frame index: 5130 Push string 0x1836018: "ª$\..." 0: /on_failure_jump to 7 3: /anychar 4: /jump to 0 7: /stop_memory/1 9: /jump to -8 12: /succeed 13: end of pattern. Push pattern 0x144aa8f: 0x144aa92: EXECUTING anychar. character.h:696: Emacs fatal error: assertion failed: CHAR_VALID_P (ch) Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:354 354 signal (sig, SIG_DFL); (gdb) bt 7 #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:354 #1 0x00000000005fdb9b in die (msg=0x725888 "CHAR_VALID_P (ch)", file=0x72587c "character.h", line=696) at alloc.c:7224 #2 0x000000000056c000 in char_table_translate (obj=20893029, ch=4195178) at character.h:696 #3 0x00000000005eb8db in re_match_2_internal (bufp=0xd6d650 <searchbufs+5072>, string1=0x1835980 "\336[\203\001", size1=0, string2=0x1835980 "\336[\203\001", size2=40918, pos=0, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:5454 #4 0x00000000005e9022 in re_search_2 (bufp=0xd6d650 <searchbufs+5072>, str1=0x1835980 "\336[\203\001", size1=0, str2=0x1835980 "\336[\203\001", size2=40918, startpos=0, range=40918, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:4470 #5 0x00000000005d6c06 in search_buffer (string=25301860, pos=1, pos_byte=1, lim=40891, lim_byte=40919, n=1, RE=1, trt=20893029, inverse_trt=20483397, posix=false) at search.c:1265 #6 0x00000000005d63a1 in search_command (string=25301860, bound=0, noerror=44544, count=0, direction=1, RE=1, posix=false) at search.c:1058 (More stack frames follow...) ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 13:45 ` npostavs @ 2016-10-08 14:39 ` Eli Zaretskii 2016-10-08 14:47 ` Eli Zaretskii 2016-10-08 16:57 ` npostavs 0 siblings, 2 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-08 14:39 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Sat, 08 Oct 2016 09:45:20 -0400 > > >> From: npostavs@users.sourceforge.net > >> Date: Fri, 07 Oct 2016 20:29:36 -0400 > >> Cc: 24358@debbugs.gnu.org > >> > >> npostavs@users.sourceforge.net writes: > >> > > >> >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with > >> >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp > >> >> matcher") > >> > >> icalendar--read-element has been fixed, but this still reproduces when > >> doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given > >> in the OP. > > > > Isn't that "user error"? > > Yes, but it should give "Stack overflow in regexp matcher", not overflow > the lisp stack (or assertion failure). But that's what you said (see above): "Stack overflow in regexp matcher". That's what I meant when I said "user error". > I show some more excerpts in the attached bug-24358-debug.log, but my > main finding is that string1 of re_match_2_internal is originally: > > string1=0x1835980 "DESCRIPTION;LANGUAGE= > > but then it becomes corrupted during a malloc: > > Old value = 68 'D' > New value = 0 '\000' If that string is data of a Lisp string, then a call to malloc could relocate the data. Code that holds C pointers into buffer or string text should either use SREF, or recompute the C pointer after each function call which could GC. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 14:39 ` Eli Zaretskii @ 2016-10-08 14:47 ` Eli Zaretskii 2016-10-08 16:57 ` npostavs 1 sibling, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-08 14:47 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > Date: Sat, 08 Oct 2016 17:39:10 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > > > Old value = 68 'D' > > New value = 0 '\000' > > If that string is data of a Lisp string, then a call to malloc could > relocate the data. Code that holds C pointers into buffer or string > text should either use SREF, or recompute the C pointer after each > function call which could GC. Or maybe that string was already free'd? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 14:39 ` Eli Zaretskii 2016-10-08 14:47 ` Eli Zaretskii @ 2016-10-08 16:57 ` npostavs 2016-10-08 17:23 ` Eli Zaretskii 1 sibling, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-08 16:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, peder@klingenberg.no >> Date: Sat, 08 Oct 2016 09:45:20 -0400 >> >> >> From: npostavs@users.sourceforge.net >> >> Date: Fri, 07 Oct 2016 20:29:36 -0400 >> >> Cc: 24358@debbugs.gnu.org >> >> >> >> npostavs@users.sourceforge.net writes: >> >> > >> >> >> (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error with >> >> >> 25.1.50, with 24.5 (and below) I get (error "Stack overflow in regexp >> >> >> matcher") >> >> >> >> icalendar--read-element has been fixed, but this still reproduces when >> >> doing (re-search-forward ".*\\(\n.*\\)*" nil t) on the text file given >> >> in the OP. >> > >> > Isn't that "user error"? >> >> Yes, but it should give "Stack overflow in regexp matcher", not overflow >> the lisp stack (or assertion failure). > > But that's what you said (see above): "Stack overflow in regexp > matcher". That's what I meant when I said "user error". Ah, I may have been a bit too terse there. What I meant was, in Emacs 24.5 I correctly get "Stack overflow in regexp matcher", whereas in emacs-master I get "Variable binding depth exceeds max-specpdl-size". In emacs-25 I get the assertion failure. > >> I show some more excerpts in the attached bug-24358-debug.log, but my >> main finding is that string1 of re_match_2_internal is originally: >> >> string1=0x1835980 "DESCRIPTION;LANGUAGE= >> >> but then it becomes corrupted during a malloc: >> >> Old value = 68 'D' >> New value = 0 '\000' > > If that string is data of a Lisp string, then a call to malloc could > relocate the data. Code that holds C pointers into buffer or string > text should either use SREF, or recompute the C pointer after each > function call which could GC. In that case, I believe the problem is that search_buffer calls re_search_2 with a pointer to the buffer text, and then re_match_2_internal (called by re_search_2), can allocate when doing PUSH_FAILURE_POINT because it eventually does SAFE_ALLOCA to grow the regex stack. AFAICT, this bug is still present 24.5, but because re_max_failures is set to a round number (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#27), there are fewer calls to malloc and thus less chance of relocating the particular string in question. So possible solutions I can would be to pass down the lisp reference to re_match_2_internal, or else set re_max_failures according to MAX_ALLOCA (but this would make it much smaller). search_buffer() /* Get pointers and sizes of the two strings that make up the visible portion of the buffer. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; p2 = GAP_END_ADDR; s2 = ZV_BYTE - GPT_BYTE; [...] val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), /* Don't allow match past current point */ pos_byte - BEGV_BYTE); re_match_2_internal() case on_failure_jump: EXTRACT_NUMBER_AND_INCR (mcnt, p); DEBUG_PRINT ("EXECUTING on_failure_jump %d (to %p):\n", mcnt, p + mcnt); PUSH_FAILURE_POINT (p -3, d); #define PUSH_FAILURE_POINT(pattern, string_place) do { ... ENSURE_FAIL_STACK (NUM_NONREG_ITEMS);... #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ if (!GROW_FAIL_STACK (fail_stack)) \ return -2;... #define GROW_FAIL_STACK(fail_stack) \ ... = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ min (re_max_failures * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * sizeof (fail_stack_elt_t) \ * FAIL_STACK_GROWTH_FACTOR))), \ # define REGEX_ALLOCATE_STACK(size) REGEX_ALLOCATE (size) # define REGEX_REALLOCATE_STACK(source, o, n) REGEX_REALLOCATE (source, o, n) # define REGEX_ALLOCATE SAFE_ALLOCA /* SAFE_ALLOCA normally allocates memory on the stack, but if size is larger than MAX_ALLOCA, use xmalloc to avoid overflowing the stack. */ enum MAX_ALLOCA { MAX_ALLOCA = 16 * 1024 }; #define SAFE_ALLOCA(size) ((size) < MAX_ALLOCA \ ? alloca (size) \ : (sa_must_free = true, record_xmalloc (size))) ^^^^^^^^^^^^^^^^^^^^^ ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 16:57 ` npostavs @ 2016-10-08 17:23 ` Eli Zaretskii 2016-10-08 18:52 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-08 17:23 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Sat, 08 Oct 2016 12:57:32 -0400 > > >> Old value = 68 'D' > >> New value = 0 '\000' > > > > If that string is data of a Lisp string, then a call to malloc could > > relocate the data. Code that holds C pointers into buffer or string > > text should either use SREF, or recompute the C pointer after each > > function call which could GC. > > In that case, I believe the problem is that search_buffer calls > re_search_2 with a pointer to the buffer text, and then > re_match_2_internal (called by re_search_2), can allocate when doing > PUSH_FAILURE_POINT because it eventually does SAFE_ALLOCA to grow the > regex stack. > > AFAICT, this bug is still present 24.5, but because re_max_failures is > set to a round number (see > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#27), there are fewer > calls to malloc and thus less chance of relocating the particular string > in question. > > So possible solutions I can would be to pass down the lisp reference to > re_match_2_internal, or else set re_max_failures according to MAX_ALLOCA > (but this would make it much smaller). Do you see buffer text actually changing its address in this scenario? Otherwise, we might be chasing a wild goose. (Once we establish this is the problem, we could talk about the fix. IME, pointers could still be passed, but some extra caution is needed when using them.) Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 17:23 ` Eli Zaretskii @ 2016-10-08 18:52 ` npostavs 2016-10-08 19:47 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-08 18:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder Eli Zaretskii <eliz@gnu.org> writes: > > Do you see buffer text actually changing its address in this scenario? > Otherwise, we might be chasing a wild goose. Yes, now that I know what to look for, it's easy enough. I added just this to .gdbinit: break search_command if (bound == 0) commands watch current_buffer->text->beg continue end # break only on the 2nd call to search_command ignore 3 1 And here is the result: Thread 1 "emacs" hit Breakpoint 3, search_command (string=25301860, bound=0, noerror=44544, count=0, direction=1, RE=1, posix=false) at search.c:1024 1024 EMACS_INT n = direction; Hardware watchpoint 4: current_buffer->text->beg Thread 1 "emacs" hit Hardware watchpoint 4: current_buffer->text->beg Old value = (unsigned char *) 0x18351b8 "" New value = (unsigned char *) 0x188a1b8 "" r_alloc_sbrk (size=290816) at ralloc.c:818 818 for (b = last_bloc; b != NIL_BLOC; b = b->prev) (gdb) bt 12 #0 r_alloc_sbrk (size=290816) at ralloc.c:818 #1 0x00000000006ced96 in get_contiguous_space (size=290816, position=0x1833000) at gmalloc.c:476 #2 0x00000000006cf92a in _malloc_internal_nolock (size=163840) at gmalloc.c:844 #3 0x00000000006cfe9d in _malloc_internal (size=163840) at gmalloc.c:927 #4 0x00000000006cff1a in gmalloc (size=163840) at gmalloc.c:951 #5 0x00000000006d14e4 in malloc (size=163840) at gmalloc.c:1827 #6 0x00000000005f3e6b in lmalloc (size=163840) at alloc.c:1414 #7 0x00000000005f3356 in xmalloc (size=163840) at alloc.c:821 #8 0x00000000005f38e4 in record_xmalloc (size=163840) at alloc.c:1038 #9 0x00000000005ee233 in re_match_2_internal (bufp=0xd6d650 <searchbufs+5072>, string1=0x1835988 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size1=0, string2=0x1835988 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size2=40918, pos=0, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:5844 #10 0x00000000005e9022 in re_search_2 (bufp=0xd6d650 <searchbufs+5072>, str1=0x1835988 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size1=0, str2=0x1835988 "DESCRIPTION;LANGUAGE=en-US:Nn Nnnnn\\,\\n\\nNnnnnnnnn nnn nnn nnnnnn nn nnnnnn\n nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn\n nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\\n\\nNnnn "..., size2=40918, startpos=0, range=40918, regs=0xd6deb0 <search_regs>, stop=40918) at regex.c:4470 #11 0x00000000005d6c06 in search_buffer (string=25301860, pos=1, pos_byte=1, lim=40891, lim_byte=40919, n=1, RE=1, trt=20893029, inverse_trt=20483397, posix=false) at search.c:1265 (More stack frames follow...) Lisp Backtrace: "re-search-forward" (0xffffc2e0) "progn" (0xffffc460) "unwind-protect" (0xffffc5a0) "save-current-buffer" (0xffffc710) "let" (0xffffc910) "eval-buffer" (0xffffcbf0) "load-with-code-conversion" (0xffffd158) "load" (0xffffd4e8) "command-line-1" (0xffffda30) "command-line" (0xffffdfe8) "normal-top-level" (0xffffe490) ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 18:52 ` npostavs @ 2016-10-08 19:47 ` Eli Zaretskii 2016-10-08 20:55 ` npostavs 2016-10-13 1:29 ` npostavs 0 siblings, 2 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-08 19:47 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Sat, 08 Oct 2016 14:52:26 -0400 > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > Do you see buffer text actually changing its address in this scenario? > > Otherwise, we might be chasing a wild goose. > > Yes, now that I know what to look for, it's easy enough. I added just > this to .gdbinit: > > break search_command if (bound == 0) > commands > watch current_buffer->text->beg > continue > end > # break only on the 2nd call to search_command > ignore 3 1 > > And here is the result: > > Thread 1 "emacs" hit Breakpoint 3, search_command (string=25301860, bound=0, noerror=44544, count=0, > direction=1, RE=1, posix=false) at search.c:1024 > 1024 EMACS_INT n = direction; > Hardware watchpoint 4: current_buffer->text->beg > > Thread 1 "emacs" hit Hardware watchpoint 4: current_buffer->text->beg > > Old value = (unsigned char *) 0x18351b8 "" > New value = (unsigned char *) 0x188a1b8 "" > r_alloc_sbrk (size=290816) at ralloc.c:818 r_alloc_sbrk? What OS is this? We only use ralloc.c on a handful of them, as of Emacs 25. Anyway, the way to countermand this is to record in a local variable the offset from beginning of buffer text to the value of the C pointer before the call to record_xmalloc, then apply the offset after the call to the new buffer text address. (Let me know if this is clear enough.) You can find an example of this in coding.c:decode_coding_emacs_mule (search for "relocated" in that function). Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 19:47 ` Eli Zaretskii @ 2016-10-08 20:55 ` npostavs 2016-10-09 6:52 ` Eli Zaretskii 2016-10-13 1:29 ` npostavs 1 sibling, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-08 20:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder Eli Zaretskii <eliz@gnu.org> writes: >> >> Thread 1 "emacs" hit Hardware watchpoint 4: current_buffer->text->beg >> >> Old value = (unsigned char *) 0x18351b8 "" >> New value = (unsigned char *) 0x188a1b8 "" >> r_alloc_sbrk (size=290816) at ralloc.c:818 > > r_alloc_sbrk? What OS is this? We only use ralloc.c on a handful of > them, as of Emacs 25. Uh, it's GNU/Linux (Arch), so not too obscure I would think. Where is the decision to use ralloc made? Maybe something went wrong in my configure? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 20:55 ` npostavs @ 2016-10-09 6:52 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-09 6:52 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Sat, 08 Oct 2016 16:55:17 -0400 > > > r_alloc_sbrk? What OS is this? We only use ralloc.c on a handful of > > them, as of Emacs 25. > > Uh, it's GNU/Linux (Arch), so not too obscure I would think. I thought no GNU/Linux system uses ralloc.c, but maybe I was mistaken. > Where is the decision to use ralloc made? It was always a fallback, for systems that don't have better ways of allocating system memory. MS-Windows was using it until 25.1. > Maybe something went wrong in my configure? I guess configure somehow decides that gmalloc.c should be used on your system (as opposed to the system-provided malloc), and then ralloc.c is a necessity. Look in your config.log for any test related to malloc or something that has "malloc" as its substring. In any case, this doesn't invalidate the bug, of course. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-08 19:47 ` Eli Zaretskii 2016-10-08 20:55 ` npostavs @ 2016-10-13 1:29 ` npostavs 2016-10-13 6:19 ` Eli Zaretskii 1 sibling, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-13 1:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder I wrote: >>>> So possible solutions I can would be to pass down the lisp reference to >>>> re_match_2_internal, [...] Eli Zaretskii <eliz@gnu.org> writes: >>> (Once we establish this is the problem, we could talk about the fix. >>> IME, pointers could still be passed, but some extra caution is needed >>> when using them.) [...] > Anyway, the way to countermand this is to record in a local variable > the offset from beginning of buffer text to the value of the C pointer > before the call to record_xmalloc, then apply the offset after the > call to the new buffer text address. (Let me know if this is clear > enough.) > > You can find an example of this in coding.c:decode_coding_emacs_mule > (search for "relocated" in that function). This does involve passing down the lisp reference, right? Just want to make sure I'm not missing something obvious before I start changing the interface on a bunch of functions. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-13 1:29 ` npostavs @ 2016-10-13 6:19 ` Eli Zaretskii 2016-10-14 2:19 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-13 6:19 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Wed, 12 Oct 2016 21:29:34 -0400 > > > Anyway, the way to countermand this is to record in a local variable > > the offset from beginning of buffer text to the value of the C pointer > > before the call to record_xmalloc, then apply the offset after the > > call to the new buffer text address. (Let me know if this is clear > > enough.) > > > > You can find an example of this in coding.c:decode_coding_emacs_mule > > (search for "relocated" in that function). > > This does involve passing down the lisp reference, right? Just want to > make sure I'm not missing something obvious before I start changing the > interface on a bunch of functions. Aren't we talking about searching buffer text in this case? If so, the start address of the buffer text is known globally, it is given by current_buffer->text->beg. You just need to calculate the difference between the start address before and after the call to malloc, or to a function that might call malloc. Alternatively (and more safely), save the value of PTR_BYTE_POS before the call to malloc, and restore the C text pointer after malloc with BYTE_POS_ADDR. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-13 6:19 ` Eli Zaretskii @ 2016-10-14 2:19 ` npostavs 2016-10-14 7:02 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-14 2:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, peder Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, peder@klingenberg.no >> Date: Wed, 12 Oct 2016 21:29:34 -0400 >> >> > Anyway, the way to countermand this is to record in a local variable >> > the offset from beginning of buffer text to the value of the C pointer >> > before the call to record_xmalloc, then apply the offset after the >> > call to the new buffer text address. (Let me know if this is clear >> > enough.) >> > >> > You can find an example of this in coding.c:decode_coding_emacs_mule >> > (search for "relocated" in that function). >> >> This does involve passing down the lisp reference, right? Just want to >> make sure I'm not missing something obvious before I start changing the >> interface on a bunch of functions. > > Aren't we talking about searching buffer text in this case? If so, > the start address of the buffer text is known globally, it is given by > current_buffer->text->beg. The particular crash reported is during a buffer search, but the bug is in re_match_2_internal which (if I understand correctly) may be called for string search as well. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-14 2:19 ` npostavs @ 2016-10-14 7:02 ` Eli Zaretskii 2016-10-19 3:11 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-14 7:02 UTC (permalink / raw) To: npostavs; +Cc: 24358, peder > X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM, > T_DKIM_INVALID autolearn=disabled version=3.3.2 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > Date: Thu, 13 Oct 2016 22:19:09 -0400 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: npostavs@users.sourceforge.net > >> Cc: 24358@debbugs.gnu.org, peder@klingenberg.no > >> Date: Wed, 12 Oct 2016 21:29:34 -0400 > >> > >> > Anyway, the way to countermand this is to record in a local variable > >> > the offset from beginning of buffer text to the value of the C pointer > >> > before the call to record_xmalloc, then apply the offset after the > >> > call to the new buffer text address. (Let me know if this is clear > >> > enough.) > >> > > >> > You can find an example of this in coding.c:decode_coding_emacs_mule > >> > (search for "relocated" in that function). > >> > >> This does involve passing down the lisp reference, right? Just want to > >> make sure I'm not missing something obvious before I start changing the > >> interface on a bunch of functions. > > > > Aren't we talking about searching buffer text in this case? If so, > > the start address of the buffer text is known globally, it is given by > > current_buffer->text->beg. > > The particular crash reported is during a buffer search, but the bug is > in re_match_2_internal which (if I understand correctly) may be called > for string search as well. Then yes, you will need to somehow pass down the object from which the text comes. It can be in some global variable, for instance, if changing the function's signature is undesirable. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-14 7:02 ` Eli Zaretskii @ 2016-10-19 3:11 ` npostavs 2016-10-19 7:02 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-19 3:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Sam Halliday, 24358 [-- Attachment #1: Type: text/plain, Size: 813 bytes --] tags 24358 patch quit Eli Zaretskii <eliz@gnu.org> writes: > > Then yes, you will need to somehow pass down the object from which the > text comes. It can be in some global variable, for instance, if > changing the function's signature is undesirable. I decided that a global variable would be a bad idea since it would still effectively be part of the calling convention, and too easy for callers to forget. But just after finishing the patch I noticed this: /* In Emacs, this is the string or buffer in which we are matching. It is used for looking up syntax properties. */ Lisp_Object re_match_object; So now I'm thinking it might be better to reuse that variable instead. Although it only seems to get to Qt, Qnil, and string objects; I'm not sure what the meaning of Qt and Qnil are. [-- Attachment #2: patch v1 --] [-- Type: text/plain, Size: 16796 bytes --] From 1016c78fe51183ed4d89eeb90c1c06f43c23cbb8 Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Mon, 17 Oct 2016 22:17:27 -0400 Subject: [PATCH v1] Fix handling of allocation in regex matching `re_match_2_internal' uses pointers to the lisp objects that it searches. Since it may call malloc when growing the "fail stack", these pointers may be invalidated while searching, resulting in memory curruption (Bug #24358). To fix this, we check the pointer that the lisp object points to before and after growing the stack, and update existing pointers accordingly. This means that all callers of regex searching functions must pass a reference to the lisp object that they search. Callers searching pure C strings that can't relocate pass Qnil. To reduce the need for preprocessor conditionals, we define Lisp_Object as an enum with just the value Qnil when building regex.c for non-emacs programs (etags). * src/regex.c (STR_BASE_PTR): New macro. (ENSURE_FAIL_STACK): Use it to update pointers after growing the stack. (re_search, re_search_2, re_match_2, re_match_2_internal): Add BASE parameter. * src/dired.c (directory_files_internal): * src/search.c (looking_at_1, string_match_1): (fast_string_match_internal, fast_looking_at, search_buffer): Pass the searched lisp object to re_search, re_search_2, re_match_2 as the BASE parameter. * src/search.c (fast_c_string_match_ignore_case): Pass Qnil as BASE parameter. * lib-src/etags.c (regex_tag_multiline): * src/regex.c (re_match, regexec) [!emacs]: Pass dummy NO_LISP arg for BASE. * src/regex.h (Lisp_Object) [!emacs]: New single valued enum. --- lib-src/etags.c | 2 +- src/dired.c | 2 +- src/regex.c | 79 +++++++++++++++++++++++++++++++++++++++++---------------- src/regex.h | 12 ++++++++- src/search.c | 45 +++++++++++++++++++------------- 5 files changed, 98 insertions(+), 42 deletions(-) diff --git a/lib-src/etags.c b/lib-src/etags.c index 1457700..c8fffc2 100644 --- a/lib-src/etags.c +++ b/lib-src/etags.c @@ -6304,7 +6304,7 @@ regex_tag_multiline (void) while (match >= 0 && match < filebuf.len) { - match = re_search (rp->pat, buffer, filebuf.len, charno, + match = re_search (rp->pat, NO_LISP, buffer, filebuf.len, charno, filebuf.len - match, &rp->regs); switch (match) { diff --git a/src/dired.c b/src/dired.c index dba575c..a558aa2 100644 --- a/src/dired.c +++ b/src/dired.c @@ -259,7 +259,7 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, QUIT; bool wanted = (NILP (match) - || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); + || re_search (bufp, name, SSDATA (name), len, 0, len, 0) >= 0); immediate_quit = 0; diff --git a/src/regex.c b/src/regex.c index 164eb46..659b1f9 100644 --- a/src/regex.c +++ b/src/regex.c @@ -533,12 +533,11 @@ init_syntax_once (void) typedef char boolean; -static regoff_t re_match_2_internal (struct re_pattern_buffer *bufp, - re_char *string1, size_t size1, - re_char *string2, size_t size2, - ssize_t pos, - struct re_registers *regs, - ssize_t stop); +static regoff_t +re_match_2_internal (struct re_pattern_buffer *bufp, Lisp_Object string_base, + const_re_char *string1, size_t size1, + const_re_char *string2, size_t size2, + ssize_t pos, struct re_registers *regs, ssize_t stop); \f /* These are the command codes that appear in compiled regular expressions. Some opcodes are followed by argument bytes. A @@ -1436,11 +1435,38 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer #define TOP_FAILURE_HANDLE() fail_stack.frame +#ifdef emacs +#define STR_BASE_PTR(obj) \ + (BUFFERP (obj)? XBUFFER (obj)->text->beg : \ + STRINGP (obj)? SDATA (obj) : \ + NULL) +#else +#define STR_BASE_PTR(obj) ((re_char*)0) +#endif #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ + re_char* orig_base = STR_BASE_PTR (string_base); \ if (!GROW_FAIL_STACK (fail_stack)) \ - return -2; \ + return -2; \ + /* GROW_FAIL_STACK may call malloc and relocate the string */ \ + /* pointers. */ \ + ptrdiff_t delta = STR_BASE_PTR (string_base) - orig_base; \ + if (string1) \ + { \ + string1 += delta; \ + end1 += delta; \ + end_match_1 += delta; \ + } \ + if (string2) \ + { \ + string2 += delta; \ + end2 += delta; \ + end_match_2 += delta; \ + } \ + d += delta; \ + dend += delta; \ + dfail += delta; \ DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ } @@ -4222,10 +4248,11 @@ WEAK_ALIAS (__re_set_registers, re_set_registers) doesn't let you say where to stop matching. */ regoff_t -re_search (struct re_pattern_buffer *bufp, const char *string, size_t size, +re_search (struct re_pattern_buffer *bufp, + Lisp_Object base, const char *string, size_t size, ssize_t startpos, ssize_t range, struct re_registers *regs) { - return re_search_2 (bufp, NULL, 0, string, size, startpos, range, + return re_search_2 (bufp, base, NULL, 0, string, size, startpos, range, regs, size); } WEAK_ALIAS (__re_search, re_search) @@ -4260,8 +4287,10 @@ WEAK_ALIAS (__re_search, re_search) stack overflow). */ regoff_t -re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, - const char *str2, size_t size2, ssize_t startpos, ssize_t range, +re_search_2 (struct re_pattern_buffer *bufp, Lisp_Object str_base, + const char *str1, size_t size1, + const char *str2, size_t size2, + ssize_t startpos, ssize_t range, struct re_registers *regs, ssize_t stop) { regoff_t val; @@ -4443,7 +4472,8 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, && !bufp->can_be_null) return -1; - val = re_match_2_internal (bufp, string1, size1, string2, size2, + val = re_match_2_internal (bufp, str_base, + string1, size1, string2, size2, startpos, regs, stop); if (val >= 0) @@ -4879,8 +4909,10 @@ mutually_exclusive_p (struct re_pattern_buffer *bufp, const_re_char *p1, re_match (struct re_pattern_buffer *bufp, const char *string, size_t size, ssize_t pos, struct re_registers *regs) { - regoff_t result = re_match_2_internal (bufp, NULL, 0, (re_char*) string, - size, pos, regs, size); + regoff_t result = re_match_2_internal (bufp, NO_LISP, + NULL, 0, + (re_char*) string, size, + pos, regs, size); return result; } WEAK_ALIAS (__re_match, re_match) @@ -4906,9 +4938,10 @@ WEAK_ALIAS (__re_match, re_match) matched substring. */ regoff_t -re_match_2 (struct re_pattern_buffer *bufp, const char *string1, - size_t size1, const char *string2, size_t size2, ssize_t pos, - struct re_registers *regs, ssize_t stop) +re_match_2 (struct re_pattern_buffer *bufp, Lisp_Object base, + const char *string1, size_t size1, + const char *string2, size_t size2, + ssize_t pos, struct re_registers *regs, ssize_t stop) { regoff_t result; @@ -4919,8 +4952,9 @@ re_match_2 (struct re_pattern_buffer *bufp, const char *string1, SETUP_SYNTAX_TABLE_FOR_OBJECT (re_match_object, charpos, 1); #endif - result = re_match_2_internal (bufp, (re_char*) string1, size1, - (re_char*) string2, size2, + result = re_match_2_internal (bufp, base, + (re_char*) string1, size1, + (re_char*) string2, size2, pos, regs, stop); return result; } @@ -4930,8 +4964,9 @@ WEAK_ALIAS (__re_match_2, re_match_2) /* This is a separate function so that we can force an alloca cleanup afterwards. */ static regoff_t -re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1, - size_t size1, const_re_char *string2, size_t size2, +re_match_2_internal (struct re_pattern_buffer *bufp, Lisp_Object string_base, + const_re_char *string1, size_t size1, + const_re_char *string2, size_t size2, ssize_t pos, struct re_registers *regs, ssize_t stop) { /* General temporaries. */ @@ -6572,7 +6607,7 @@ regexec (const regex_t *_Restrict_ preg, const char *_Restrict_ string, by '\n' which would throw things off. */ /* Perform the searching operation. */ - ret = re_search (&private_preg, string, len, + ret = re_search (&private_preg, NO_LISP, string, len, /* start: */ 0, /* range: */ len, want_reg_info ? ®s : 0); diff --git a/src/regex.h b/src/regex.h index 817167a..4810bc4 100644 --- a/src/regex.h +++ b/src/regex.h @@ -469,13 +469,21 @@ extern const char *re_compile_pattern (const char *__pattern, size_t __length, internal error. */ extern int re_compile_fastmap (struct re_pattern_buffer *__buffer); +#ifndef emacs +/* Define Lisp_Object outside of emacs, just so something can be + passed as the BASE parameter to re_search and re_match. */ +typedef enum { NO_LISP } Lisp_Object; +#endif /* Search in the string STRING (with length LENGTH) for the pattern compiled into BUFFER. Start searching at position START, for RANGE characters. Return the starting position of the match, -1 for no match, or -2 for an internal error. Also return register - information in REGS (if REGS and BUFFER->no_sub are nonzero). */ + information in REGS (if REGS and BUFFER->no_sub are nonzero). If + STRING is a pointer into a lisp object, pass the object as BASE in + order to correctly handle relocation if re_search calls malloc. */ extern regoff_t re_search (struct re_pattern_buffer *__buffer, + Lisp_Object __base, const char *__string, size_t __length, ssize_t __start, ssize_t __range, struct re_registers *__regs); @@ -484,6 +492,7 @@ extern regoff_t re_search (struct re_pattern_buffer *__buffer, /* Like `re_search', but search in the concatenation of STRING1 and STRING2. Also, stop searching at index START + STOP. */ extern regoff_t re_search_2 (struct re_pattern_buffer *__buffer, + Lisp_Object __base, const char *__string1, size_t __length1, const char *__string2, size_t __length2, ssize_t __start, ssize_t __range, @@ -500,6 +509,7 @@ extern regoff_t re_match (struct re_pattern_buffer *__buffer, /* Relates to `re_match' as `re_search_2' relates to `re_search'. */ extern regoff_t re_match_2 (struct re_pattern_buffer *__buffer, + Lisp_Object __base, const char *__string1, size_t __length1, const char *__string2, size_t __length2, ssize_t __start, struct re_registers *__regs, diff --git a/src/search.c b/src/search.c index dc7e2d8..3d3d355 100644 --- a/src/search.c +++ b/src/search.c @@ -287,8 +287,10 @@ looking_at_1 (Lisp_Object string, bool posix) immediate_quit = 1; QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get pointers and sizes of the two strings that make up the + visible portion of the buffer. Note that we can use pointers + here, unlike in search_buffer, because we only call re_match_2 + once. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; @@ -308,7 +310,8 @@ looking_at_1 (Lisp_Object string, bool posix) re_match_object = Qnil; - i = re_match_2 (bufp, (char *) p1, s1, (char *) p2, s2, + i = re_match_2 (bufp, Fcurrent_buffer (), + (char *) p1, s1, (char *) p2, s2, PT_BYTE - BEGV_BYTE, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL), @@ -401,7 +404,7 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, immediate_quit = 1; re_match_object = string; - val = re_search (bufp, SSDATA (string), + val = re_search (bufp, string, SSDATA (string), SBYTES (string), pos_byte, SBYTES (string) - pos_byte, (NILP (Vinhibit_changing_match_data) @@ -473,7 +476,7 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, immediate_quit = 1; re_match_object = string; - val = re_search (bufp, SSDATA (string), + val = re_search (bufp, string, SSDATA (string), SBYTES (string), 0, SBYTES (string), 0); immediate_quit = 0; @@ -498,7 +501,7 @@ fast_c_string_match_ignore_case (Lisp_Object regexp, Vascii_canon_table, 0, 0); immediate_quit = 1; - val = re_search (bufp, string, len, 0, len, 0); + val = re_search (bufp, Qnil, string, len, 0, len, 0); immediate_quit = 0; return val; } @@ -561,7 +564,8 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, buf = compile_pattern (regexp, 0, Qnil, 0, multibyte); immediate_quit = 1; - len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, + len = re_match_2 (buf, Fcurrent_buffer (), + (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); immediate_quit = 0; @@ -1178,8 +1182,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) { - unsigned char *p1, *p2; - ptrdiff_t s1, s2; + unsigned char *base; + ptrdiff_t off1, off2, s1, s2; struct re_pattern_buffer *bufp; bufp = compile_pattern (string, @@ -1193,16 +1197,19 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, can take too long. */ QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get offsets and sizes of the two strings that make up the + visible portion of the buffer. We compute offsets instead of + pointers because re_search_2 may call malloc and therefore + change the buffer text address. */ - p1 = BEGV_ADDR; + base = current_buffer->text->beg; + off1 = BEGV_ADDR - base; s1 = GPT_BYTE - BEGV_BYTE; - p2 = GAP_END_ADDR; + off2 = GAP_END_ADDR - base; s2 = ZV_BYTE - GPT_BYTE; if (s1 < 0) { - p2 = p1; + off2 = off1; s2 = ZV_BYTE - BEGV_BYTE; s1 = 0; } @@ -1217,7 +1224,9 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, + val = re_search_2 (bufp, Fcurrent_buffer (), + (char*) (base + off1), s1, + (char*) (base + off2), s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), @@ -1262,8 +1271,10 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, - pos_byte - BEGV_BYTE, lim_byte - pos_byte, + val = re_search_2 (bufp, Fcurrent_buffer (), + (char*) (base + off1), s1, + (char*) (base + off2), s2, + pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); -- 2.9.3 [-- Attachment #3: Type: text/plain, Size: 1003 bytes --] Sam Halliday <sam.halliday@gmail.com> writes: > > Could somebody please let me know how to dig into 0x56e5508 (if > relevant)? I have never used gdb in anger. See if you can adapt the .gdbinit modifications I posted in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#53; assuming your recipe always triggers the crash in the exact same way, it might be enough just to change the conditional to 'if (lim == 1156)', and you might not even need the ignore call at all. > I've attempted to workaround this in ensime by simplifying our loading > of the .ensime file (the s-expression) to use with-temp-buffer and not > declaring .ensime as an emacs-lisp file... it may be that one of my > minor modes, active in emacs-lisp, is performing a regexp that is > triggering this bug. If you can get the lisp backtrace it should show you what code is triggering the regexp search. It should show up automatically when you do bt, if you've sourced src/.gdbinit as described in etc/DEBUG "Configuring GDB". ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-19 3:11 ` npostavs @ 2016-10-19 7:02 ` Eli Zaretskii 2016-10-19 12:29 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-19 7:02 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, Sam Halliday <sam.halliday@gmail.com> > Date: Tue, 18 Oct 2016 23:11:45 -0400 > > > Then yes, you will need to somehow pass down the object from which the > > text comes. It can be in some global variable, for instance, if > > changing the function's signature is undesirable. > > I decided that a global variable would be a bad idea since it would > still effectively be part of the calling convention, and too easy for > callers to forget. That's true, but doing this is a standard Emacs coding practice, used in quite a few other places. > But just after finishing the patch I noticed this: > > /* In Emacs, this is the string or buffer in which we > are matching. It is used for looking up syntax properties. */ > Lisp_Object re_match_object; Indeed. > So now I'm thinking it might be better to reuse that variable instead. > Although it only seems to get to Qt, Qnil, and string objects; I'm not > sure what the meaning of Qt and Qnil are. nil means current buffer, t means a C string. (This is standard Emacs convention, used in other places as well, but you can verify it is used in this case by looking at all the places where these values are assigned.) The last case, of a C string, doesn't need to bother about relocation, of course (but you could ignore that distinction for simplicity of the code, if you want, it will never do any harm). I guess you will be rewriting your patch to use re_match_object? I expect it to be much simpler and smaller. re_match_object is already staticpro'd, btw, so you don't need to worry about GC for the Lisp object (a string) that gets put in its value. However, I think we should assign Qnil to re_match_object as soon as re_match_2 returns, to avoid having the string protected from GC for too long. A couple of comments to the patch: > +#ifdef emacs > +#define STR_BASE_PTR(obj) \ > + (BUFFERP (obj)? XBUFFER (obj)->text->beg : \ > + STRINGP (obj)? SDATA (obj) : \ > + NULL) There's an unnecessary complication here: since, when regex functions are invoked to search a buffer, that buffer is always the current buffer, you don't need to pass the buffer object and use XBUFFER, because the current buffer is always available in the global variable current_buffer (which is a C struct, not a Lisp object). So you could adopt the usual semantics of passing Qnil to mean the current buffer and a string object to mean that string. Then the only test in the macro should be STRINGP. > #define ENSURE_FAIL_STACK(space) \ > while (REMAINING_AVAIL_SLOTS <= space) { \ > + re_char* orig_base = STR_BASE_PTR (string_base); \ > if (!GROW_FAIL_STACK (fail_stack)) \ > - return -2; \ > + return -2; \ > + /* GROW_FAIL_STACK may call malloc and relocate the string */ \ > + /* pointers. */ \ > + ptrdiff_t delta = STR_BASE_PTR (string_base) - orig_base; \ > + if (string1) \ > + { \ > + string1 += delta; \ > + end1 += delta; \ > + end_match_1 += delta; \ > + } \ > + if (string2) \ > + { \ > + string2 += delta; \ > + end2 += delta; \ > + end_match_2 += delta; \ > + } \ > + d += delta; \ > + dend += delta; \ > + dfail += delta; \ I think doing this via buffer and string positions instead would yield slightly more portable code, since Standard C says subtraction of pointers to different objects yields undefined behavior. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-19 7:02 ` Eli Zaretskii @ 2016-10-19 12:29 ` npostavs 2016-10-19 14:37 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-19 12:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, Sam Halliday <sam.halliday@gmail.com> >> Date: Tue, 18 Oct 2016 23:11:45 -0400 >> >> /* In Emacs, this is the string or buffer in which we >> are matching. It is used for looking up syntax properties. */ >> Lisp_Object re_match_object; > > Indeed. > >> So now I'm thinking it might be better to reuse that variable instead. >> Although it only seems to get to Qt, Qnil, and string objects; I'm not >> sure what the meaning of Qt and Qnil are. > > nil means current buffer, t means a C string. (This is standard Emacs > convention, used in other places as well, but you can verify it is > used in this case by looking at all the places where these values are > assigned.) > It would be nice to have a comment in the code about this. I saw that it was set to nil in search_buffer etc, but that just confused me since I took nil to mean "nothing". > > I guess you will be rewriting your patch to use re_match_object? I > expect it to be much simpler and smaller. re_match_object is already > staticpro'd, btw, so you don't need to worry about GC for the Lisp > object (a string) that gets put in its value. However, I think we > should assign Qnil to re_match_object as soon as re_match_2 returns, > to avoid having the string protected from GC for too long. Do you mean staticpro prevents relocation (not just collection)? In that case wouldn't it be even simpler to assign the buffer object to re_match_object? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-19 12:29 ` npostavs @ 2016-10-19 14:37 ` Eli Zaretskii 2016-10-20 4:31 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-19 14:37 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Wed, 19 Oct 2016 08:29:48 -0400 > > > nil means current buffer, t means a C string. (This is standard Emacs > > convention, used in other places as well, but you can verify it is > > used in this case by looking at all the places where these values are > > assigned.) > > It would be nice to have a comment in the code about this. Done. (Please update the comment when you are done with the change of using that variable for this additional purpose.) > I saw that it was set to nil in search_buffer etc, but that just > confused me since I took nil to mean "nothing". Yeah, it can be confusing when you first bump into it. > > I guess you will be rewriting your patch to use re_match_object? I > > expect it to be much simpler and smaller. re_match_object is already > > staticpro'd, btw, so you don't need to worry about GC for the Lisp > > object (a string) that gets put in its value. However, I think we > > should assign Qnil to re_match_object as soon as re_match_2 returns, > > to avoid having the string protected from GC for too long. > > Do you mean staticpro prevents relocation (not just collection)? > In that case wouldn't it be even simpler to assign the buffer object to > re_match_object? No, it only makes sure the objects will not be GC'ed, it doesn't prevent relocation. Every staticpro'd variable is marked at the beginning of GC, which includes marking any Lisp object that is referenced, directly or indirectly, from the staticpro'd variable. Btw, note that regex.c already has macros PTR_TO_OFFSET and POS_AS_IN_BUFFER which you can use. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-19 14:37 ` Eli Zaretskii @ 2016-10-20 4:31 ` npostavs 2016-10-20 8:39 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-20 4:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 [-- Attachment #1: Type: text/plain, Size: 899 bytes --] Eli Zaretskii <eliz@gnu.org> writes: > >> +#ifdef emacs >> +#define STR_BASE_PTR(obj) \ >> + (BUFFERP (obj)? XBUFFER (obj)->text->beg : \ >> + STRINGP (obj)? SDATA (obj) : \ >> + NULL) > [...] > the only test in the macro should be STRINGP. > Hmm, not sure I feel comfortable being that implicit. I kept this macro the same except for using (NILP (obj)? current_buffer->...) instead of BUFFERP and XBUFFER. > > Btw, note that regex.c already has macros PTR_TO_OFFSET and > POS_AS_IN_BUFFER which you can use. AFAICT these are not useful for this: they give offets relative to string1 (or string2), which would not help to compute the new value for string1 (or string2, etc...). Since I was looking at it, I've also added a comment about the trick of punning the boolean result into buffer or string base index. ------ Here is the new patch: [-- Attachment #2: patch v2 --] [-- Type: text/plain, Size: 12538 bytes --] From 92700753ac38b947dd2a725478b07dd7ef229c3a Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Wed, 19 Oct 2016 20:23:50 -0400 Subject: [PATCH v2] Fix handling of allocation in regex matching `re_match_2_internal' uses pointers to the lisp objects that it searches. Since it may call malloc when growing the "fail stack", these pointers may be invalidated while searching, resulting in memory curruption (Bug #24358). To fix this, we check the pointer that the lisp object (as specified by re_match_object) points to before and after growing the stack, and update existing pointers accordingly. * src/regex.c (STR_BASE_PTR): New macro. (ENSURE_FAIL_STACK, re_search_2): Use it to convert pointers into offsets before possible malloc call, and back into pointers again afterwards. (POS_AS_IN_BUFFER): Add explanatory comment about punning trick. * src/search.c (search_buffer): Instead of storing search location as pointers, store them as pointers and recompute the corresponding address for each call to `re_search_2'. (string_match_1, fast_string_match_internal, fast_looking_at): * src/dired.c (directory_files_internal): Set `re_match_object' to Qnil after calling `re_search' or `re_match_2'. * src/regex.h (re_match_object): Mention new usage in commentary. --- src/dired.c | 4 +++- src/regex.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- src/regex.h | 3 ++- src/search.c | 36 ++++++++++++++++++---------- 4 files changed, 102 insertions(+), 17 deletions(-) diff --git a/src/dired.c b/src/dired.c index dba575c..006f74c 100644 --- a/src/dired.c +++ b/src/dired.c @@ -259,9 +259,11 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, QUIT; bool wanted = (NILP (match) - || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); + || (re_match_object = name, + re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0)); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting name from GC. */ if (wanted) { diff --git a/src/regex.c b/src/regex.c index 164eb46..b710f50 100644 --- a/src/regex.c +++ b/src/regex.c @@ -152,6 +152,8 @@ /* Converts the pointer to the char to BEG-based offset from the start. */ # define PTR_TO_OFFSET(d) POS_AS_IN_BUFFER (POINTER_TO_OFFSET (d)) +/* Strings are 0-indexed, buffers are 1-indexed; we pun on the boolean + result to get the right base index. */ # define POS_AS_IN_BUFFER(p) ((p) + (NILP (re_match_object) || BUFFERP (re_match_object))) # define RE_MULTIBYTE_P(bufp) ((bufp)->multibyte) @@ -1436,11 +1438,62 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer #define TOP_FAILURE_HANDLE() fail_stack.frame +#ifdef emacs +#define STR_BASE_PTR(obj) \ + (NILP(obj)? current_buffer->text->beg : \ + STRINGP (obj)? SDATA (obj) : \ + NULL) +#else +#define STR_BASE_PTR(obj) NULL +#endif #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ + re_char* orig_base = STR_BASE_PTR (re_match_object); \ + ptrdiff_t string1_off, end1_off, end_match_1_off; \ + ptrdiff_t string2_off, end2_off, end_match_2_off; \ + ptrdiff_t d_off, dend_off, dfail_off; \ + if (orig_base) \ + { \ + if (string1) \ + { \ + string1_off = string1 - orig_base; \ + end1_off = end1 - orig_base; \ + end_match_1_off = end_match_1 - orig_base; \ + } \ + if (string2) \ + { \ + string2_off = string2 - orig_base; \ + end2_off = end2 - orig_base; \ + end_match_2_off = end_match_2 - orig_base; \ + } \ + d_off = d - orig_base; \ + dend_off = dend - orig_base; \ + dfail_off = dfail - orig_base; \ + } \ if (!GROW_FAIL_STACK (fail_stack)) \ - return -2; \ + return -2; \ + /* GROW_FAIL_STACK may call malloc and relocate the string */ \ + /* pointers. */ \ + re_char* new_base = STR_BASE_PTR (re_match_object); \ + if (new_base && new_base != orig_base) \ + { \ + if (string1) \ + { \ + string1 = new_base + string1_off; \ + end1 = new_base + end1_off; \ + end_match_1 = new_base + end_match_1_off; \ + } \ + if (string2) \ + { \ + string2 = new_base + string2_off; \ + end2 = new_base + end2_off; \ + end_match_2 = new_base + end_match_2_off; \ + } \ + d = new_base + d_off; \ + dend = new_base + dend_off; \ + dfail = new_base + dfail_off; \ + } \ DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ } @@ -4443,6 +4496,16 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, && !bufp->can_be_null) return -1; + /* re_match_2_internal may allocate, causing a relocation of the + lisp text object that we're searching. */ + ptrdiff_t offset1, offset2; + re_char *orig_base = STR_BASE_PTR (re_match_object); + if (orig_base) + { + if (string1) offset1 = string1 - orig_base; + if (string2) offset2 = string2 - orig_base; + } + val = re_match_2_internal (bufp, string1, size1, string2, size2, startpos, regs, stop); @@ -4452,6 +4515,13 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, if (val == -2) return -2; + re_char *new_base = STR_BASE_PTR (re_match_object); + if (new_base && new_base != orig_base) + { + if (string1) string1 = offset1 + new_base; + if (string2) string2 = offset2 + new_base; + } + advance: if (!range) break; @@ -4887,8 +4957,8 @@ WEAK_ALIAS (__re_match, re_match) #endif /* not emacs */ #ifdef emacs -/* In Emacs, this is the string or buffer in which we - are matching. It is used for looking up syntax properties. */ +/* In Emacs, this is the string or buffer in which we are matching. + See the declaration in regex.h for details. */ Lisp_Object re_match_object; #endif diff --git a/src/regex.h b/src/regex.h index 51f4424..d5c9690 100644 --- a/src/regex.h +++ b/src/regex.h @@ -169,7 +169,8 @@ extern reg_syntax_t re_syntax_options; #ifdef emacs # include "lisp.h" /* In Emacs, this is the string or buffer in which we are matching. - It is used for looking up syntax properties. + It is used for looking up syntax properties, and also to recompute + pointers in case the object is relocated by GC. If the value is a Lisp string object, we are matching text in that string; if it's nil, we are matching text in the current buffer; if diff --git a/src/search.c b/src/search.c index dc7e2d8..9a2805d 100644 --- a/src/search.c +++ b/src/search.c @@ -287,8 +287,10 @@ looking_at_1 (Lisp_Object string, bool posix) immediate_quit = 1; QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get pointers and sizes of the two strings that make up the + visible portion of the buffer. Note that we can use pointers + here, unlike in search_buffer, because we only call re_match_2 + once. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; @@ -407,6 +409,7 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL)); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ /* Set last_thing_searched only when match data is changed. */ if (NILP (Vinhibit_changing_match_data)) @@ -477,6 +480,7 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, SBYTES (string), 0, SBYTES (string), 0); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ return val; } @@ -564,6 +568,7 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ return len; } @@ -1178,8 +1183,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) { - unsigned char *p1, *p2; - ptrdiff_t s1, s2; + unsigned char *base; + ptrdiff_t off1, off2, s1, s2; struct re_pattern_buffer *bufp; bufp = compile_pattern (string, @@ -1193,16 +1198,19 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, can take too long. */ QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get offsets and sizes of the two strings that make up the + visible portion of the buffer. We compute offsets instead of + pointers because re_search_2 may call malloc and therefore + change the buffer text address. */ - p1 = BEGV_ADDR; + base = current_buffer->text->beg; + off1 = BEGV_ADDR - base; s1 = GPT_BYTE - BEGV_BYTE; - p2 = GAP_END_ADDR; + off2 = GAP_END_ADDR - base; s2 = ZV_BYTE - GPT_BYTE; if (s1 < 0) { - p2 = p1; + off2 = off1; s2 = ZV_BYTE - BEGV_BYTE; s1 = 0; } @@ -1217,7 +1225,9 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, + val = re_search_2 (bufp, + (char*) (base + off1), s1, + (char*) (base + off2), s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), @@ -1262,8 +1272,10 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, - pos_byte - BEGV_BYTE, lim_byte - pos_byte, + val = re_search_2 (bufp, + (char*) (base + off1), s1, + (char*) (base + off2), s2, + pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); -- 2.9.3 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-20 4:31 ` npostavs @ 2016-10-20 8:39 ` Eli Zaretskii 2016-10-21 1:22 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-20 8:39 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Thu, 20 Oct 2016 00:31:50 -0400 > > Eli Zaretskii <eliz@gnu.org> writes: > > > >> +#ifdef emacs > >> +#define STR_BASE_PTR(obj) \ > >> + (BUFFERP (obj)? XBUFFER (obj)->text->beg : \ > >> + STRINGP (obj)? SDATA (obj) : \ > >> + NULL) > > > > [...] > > > the only test in the macro should be STRINGP. > > Hmm, not sure I feel comfortable being that implicit. I kept this macro > the same except for using (NILP (obj)? current_buffer->...) instead of > BUFFERP and XBUFFER. Fine with me. > Here is the new patch: LGTM, a few minor comments below. > +#ifdef emacs > +#define STR_BASE_PTR(obj) \ > + (NILP(obj)? current_buffer->text->beg : \ ^ Please leave a blank before the left parenthesis where indicated. Also, another blank between the right parenthesis and the following question mark. > + STRINGP (obj)? SDATA (obj) : \ Likewise here. > diff --git a/src/regex.h b/src/regex.h > index 51f4424..d5c9690 100644 > --- a/src/regex.h > +++ b/src/regex.h > @@ -169,7 +169,8 @@ extern reg_syntax_t re_syntax_options; > #ifdef emacs > # include "lisp.h" > /* In Emacs, this is the string or buffer in which we are matching. > - It is used for looking up syntax properties. > + It is used for looking up syntax properties, and also to recompute > + pointers in case the object is relocated by GC. Not "by GC", but "as a side effect of calling malloc". Maybe it's a good idea to also mention ralloc.c here. > + /* Get pointers and sizes of the two strings that make up the > + visible portion of the buffer. Note that we can use pointers > + here, unlike in search_buffer, because we only call re_match_2 > + once. */ I'm not sure the reader will understand the significance of calling re_match_2 only once. It would be good to clarify the comment. Otherwise, I think this should go in. Thanks! ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-20 8:39 ` Eli Zaretskii @ 2016-10-21 1:22 ` npostavs 2016-10-21 7:17 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-21 1:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 [-- Attachment #1: Type: text/plain, Size: 1368 bytes --] Eli Zaretskii <eliz@gnu.org> writes: > >> +#ifdef emacs >> +#define STR_BASE_PTR(obj) \ >> + (NILP(obj)? current_buffer->text->beg : \ > ^ > Please leave a blank before the left parenthesis where indicated. > Also, another blank between the right parenthesis and the following > question mark. > >> + STRINGP (obj)? SDATA (obj) : \ > > Likewise here. Damn, I can't I believe I'm still making these formatting errors, there's got to be a way to catch these automatically. >> + It is used for looking up syntax properties, and also to recompute >> + pointers in case the object is relocated by GC. > > Not "by GC", but "as a side effect of calling malloc". Maybe it's a > good idea to also mention ralloc.c here. > >> + /* Get pointers and sizes of the two strings that make up the >> + visible portion of the buffer. Note that we can use pointers >> + here, unlike in search_buffer, because we only call re_match_2 >> + once. */ > > I'm not sure the reader will understand the significance of calling > re_match_2 only once. It would be good to clarify the comment. Okay, I've added some more explanations to these comments. > > Otherwise, I think this should go in. This is for emacs-25, right? Technically, the bug seems to be present in 24.5 and earlier, though I can only trigger it in 25.1. [-- Attachment #2: patch v3 --] [-- Type: text/plain, Size: 12666 bytes --] From 97b69a66148c0b28c6d865619b6c1bcee78902a5 Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Wed, 19 Oct 2016 20:23:50 -0400 Subject: [PATCH v3] Fix handling of allocation in regex matching `re_match_2_internal' uses pointers to the lisp objects that it searches. Since it may call malloc when growing the "fail stack", these pointers may be invalidated while searching, resulting in memory curruption (Bug #24358). To fix this, we check the pointer that the lisp object (as specified by re_match_object) points to before and after growing the stack, and update existing pointers accordingly. * src/regex.c (STR_BASE_PTR): New macro. (ENSURE_FAIL_STACK, re_search_2): Use it to convert pointers into offsets before possible malloc call, and back into pointers again afterwards. (POS_AS_IN_BUFFER): Add explanatory comment about punning trick. * src/search.c (search_buffer): Instead of storing search location as pointers, store them as pointers and recompute the corresponding address for each call to `re_search_2'. (string_match_1, fast_string_match_internal, fast_looking_at): * src/dired.c (directory_files_internal): Set `re_match_object' to Qnil after calling `re_search' or `re_match_2'. * src/regex.h (re_match_object): Mention new usage in commentary. --- src/dired.c | 4 +++- src/regex.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- src/regex.h | 4 +++- src/search.c | 36 ++++++++++++++++++---------- 4 files changed, 103 insertions(+), 17 deletions(-) diff --git a/src/dired.c b/src/dired.c index dba575c..006f74c 100644 --- a/src/dired.c +++ b/src/dired.c @@ -259,9 +259,11 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, QUIT; bool wanted = (NILP (match) - || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); + || (re_match_object = name, + re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0)); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting name from GC. */ if (wanted) { diff --git a/src/regex.c b/src/regex.c index 164eb46..1346ef4 100644 --- a/src/regex.c +++ b/src/regex.c @@ -152,6 +152,8 @@ /* Converts the pointer to the char to BEG-based offset from the start. */ # define PTR_TO_OFFSET(d) POS_AS_IN_BUFFER (POINTER_TO_OFFSET (d)) +/* Strings are 0-indexed, buffers are 1-indexed; we pun on the boolean + result to get the right base index. */ # define POS_AS_IN_BUFFER(p) ((p) + (NILP (re_match_object) || BUFFERP (re_match_object))) # define RE_MULTIBYTE_P(bufp) ((bufp)->multibyte) @@ -1436,11 +1438,62 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer #define TOP_FAILURE_HANDLE() fail_stack.frame +#ifdef emacs +#define STR_BASE_PTR(obj) \ + (NILP (obj) ? current_buffer->text->beg : \ + STRINGP (obj) ? SDATA (obj) : \ + NULL) +#else +#define STR_BASE_PTR(obj) NULL +#endif #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ + re_char* orig_base = STR_BASE_PTR (re_match_object); \ + ptrdiff_t string1_off, end1_off, end_match_1_off; \ + ptrdiff_t string2_off, end2_off, end_match_2_off; \ + ptrdiff_t d_off, dend_off, dfail_off; \ + if (orig_base) \ + { \ + if (string1) \ + { \ + string1_off = string1 - orig_base; \ + end1_off = end1 - orig_base; \ + end_match_1_off = end_match_1 - orig_base; \ + } \ + if (string2) \ + { \ + string2_off = string2 - orig_base; \ + end2_off = end2 - orig_base; \ + end_match_2_off = end_match_2 - orig_base; \ + } \ + d_off = d - orig_base; \ + dend_off = dend - orig_base; \ + dfail_off = dfail - orig_base; \ + } \ if (!GROW_FAIL_STACK (fail_stack)) \ - return -2; \ + return -2; \ + /* GROW_FAIL_STACK may call malloc and relocate the string */ \ + /* pointers. */ \ + re_char* new_base = STR_BASE_PTR (re_match_object); \ + if (new_base && new_base != orig_base) \ + { \ + if (string1) \ + { \ + string1 = new_base + string1_off; \ + end1 = new_base + end1_off; \ + end_match_1 = new_base + end_match_1_off; \ + } \ + if (string2) \ + { \ + string2 = new_base + string2_off; \ + end2 = new_base + end2_off; \ + end_match_2 = new_base + end_match_2_off; \ + } \ + d = new_base + d_off; \ + dend = new_base + dend_off; \ + dfail = new_base + dfail_off; \ + } \ DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ } @@ -4443,6 +4496,16 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, && !bufp->can_be_null) return -1; + /* re_match_2_internal may allocate, causing a relocation of the + lisp text object that we're searching. */ + ptrdiff_t offset1, offset2; + re_char *orig_base = STR_BASE_PTR (re_match_object); + if (orig_base) + { + if (string1) offset1 = string1 - orig_base; + if (string2) offset2 = string2 - orig_base; + } + val = re_match_2_internal (bufp, string1, size1, string2, size2, startpos, regs, stop); @@ -4452,6 +4515,13 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, if (val == -2) return -2; + re_char *new_base = STR_BASE_PTR (re_match_object); + if (new_base && new_base != orig_base) + { + if (string1) string1 = offset1 + new_base; + if (string2) string2 = offset2 + new_base; + } + advance: if (!range) break; @@ -4887,8 +4957,8 @@ WEAK_ALIAS (__re_match, re_match) #endif /* not emacs */ #ifdef emacs -/* In Emacs, this is the string or buffer in which we - are matching. It is used for looking up syntax properties. */ +/* In Emacs, this is the string or buffer in which we are matching. + See the declaration in regex.h for details. */ Lisp_Object re_match_object; #endif diff --git a/src/regex.h b/src/regex.h index 51f4424..61c771c 100644 --- a/src/regex.h +++ b/src/regex.h @@ -169,7 +169,9 @@ extern reg_syntax_t re_syntax_options; #ifdef emacs # include "lisp.h" /* In Emacs, this is the string or buffer in which we are matching. - It is used for looking up syntax properties. + It is used for looking up syntax properties, and also to recompute + pointers in case the object is relocated as a side effect of + calling malloc (if it calls r_alloc_sbrk in ralloc.c). If the value is a Lisp string object, we are matching text in that string; if it's nil, we are matching text in the current buffer; if diff --git a/src/search.c b/src/search.c index dc7e2d8..ec5a1d7 100644 --- a/src/search.c +++ b/src/search.c @@ -287,8 +287,10 @@ looking_at_1 (Lisp_Object string, bool posix) immediate_quit = 1; QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get pointers and sizes of the two strings that make up the + visible portion of the buffer. Note that we can use pointers + here, unlike in search_buffer, because we only call re_match_2 + once, after which we never use the pointers again. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; @@ -407,6 +409,7 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL)); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ /* Set last_thing_searched only when match data is changed. */ if (NILP (Vinhibit_changing_match_data)) @@ -477,6 +480,7 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, SBYTES (string), 0, SBYTES (string), 0); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ return val; } @@ -564,6 +568,7 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); immediate_quit = 0; + re_match_object = Qnil; /* Stop protecting string from GC. */ return len; } @@ -1178,8 +1183,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) { - unsigned char *p1, *p2; - ptrdiff_t s1, s2; + unsigned char *base; + ptrdiff_t off1, off2, s1, s2; struct re_pattern_buffer *bufp; bufp = compile_pattern (string, @@ -1193,16 +1198,19 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, can take too long. */ QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings - that make up the visible portion of the buffer. */ + /* Get offsets and sizes of the two strings that make up the + visible portion of the buffer. We compute offsets instead of + pointers because re_search_2 may call malloc and therefore + change the buffer text address. */ - p1 = BEGV_ADDR; + base = current_buffer->text->beg; + off1 = BEGV_ADDR - base; s1 = GPT_BYTE - BEGV_BYTE; - p2 = GAP_END_ADDR; + off2 = GAP_END_ADDR - base; s2 = ZV_BYTE - GPT_BYTE; if (s1 < 0) { - p2 = p1; + off2 = off1; s2 = ZV_BYTE - BEGV_BYTE; s1 = 0; } @@ -1217,7 +1225,9 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, + val = re_search_2 (bufp, + (char*) (base + off1), s1, + (char*) (base + off2), s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), @@ -1262,8 +1272,10 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, - pos_byte - BEGV_BYTE, lim_byte - pos_byte, + val = re_search_2 (bufp, + (char*) (base + off1), s1, + (char*) (base + off2), s2, + pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); -- 2.9.3 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-21 1:22 ` npostavs @ 2016-10-21 7:17 ` Eli Zaretskii 2016-10-22 2:36 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-21 7:17 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Thu, 20 Oct 2016 21:22:25 -0400 > > > Otherwise, I think this should go in. > > This is for emacs-25, right? Technically, the bug seems to be present > in 24.5 and earlier, though I can only trigger it in 25.1. Yes, please push to emacs-25. The bug is sufficiently nasty and the solution simple enough to justify that. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-21 7:17 ` Eli Zaretskii @ 2016-10-22 2:36 ` npostavs 2016-10-22 21:54 ` Sam Halliday 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-22 2:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 # This one was about the memory corruption, # for the max-specpdl-size problem, see Bug #24751. retitle 24358 Memory corruption after r_alloc_sbrk during regex matching found 24358 25.1 tags 24358 fixed close 24358 25.2 quit Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com >> Date: Thu, 20 Oct 2016 21:22:25 -0400 >> >> > Otherwise, I think this should go in. >> >> This is for emacs-25, right? Technically, the bug seems to be present >> in 24.5 and earlier, though I can only trigger it in 25.1. > > Yes, please push to emacs-25. The bug is sufficiently nasty and the > solution simple enough to justify that. I've pushed as ad66b3fa. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-22 2:36 ` npostavs @ 2016-10-22 21:54 ` Sam Halliday 2016-10-22 22:46 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-22 21:54 UTC (permalink / raw) To: npostavs, Eli Zaretskii; +Cc: 24358 [-- Attachment #1: Type: text/plain, Size: 932 bytes --] when I build emacs-25 with this patch (either by building emacs-25 directly or taking emacs-25.1 and applying this patch) I get a failure in make: ./autogen.sh CFLAGS='-O0 -g3 -gdwarf-4' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type --prefix=/opt/emacs25 make . . . make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/admin/grammars' collected 50% ... collected 60% ... collected 70% ... collected 80% ... collected 90% ... Processing OKURI-NASI entries ... processed 10% ... processed 20% ... Args out of range: #("崎/ かん" 0 5 (charset japanese-jisx0208)), -6, nil make[2]: *** [Makefile:142: ../lisp/leim/ja-dic/ja-dic.el] Error 255 make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/leim' make[1]: *** [Makefile:320: leim] Error 2 make[1]: Leaving directory '/home/fommil/build/emacs-git/emacs/lisp' make: *** [Makefile:385: lisp] Error 2 [-- Attachment #2.1: Type: text/plain, Size: 851 bytes --] npostavs@users.sourceforge.net writes: > # This one was about the memory corruption, > # for the max-specpdl-size problem, see Bug #24751. > retitle 24358 Memory corruption after r_alloc_sbrk during regex matching > found 24358 25.1 > tags 24358 fixed > close 24358 25.2 > quit > > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: npostavs@users.sourceforge.net >>> Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com >>> Date: Thu, 20 Oct 2016 21:22:25 -0400 >>> >>> > Otherwise, I think this should go in. >>> >>> This is for emacs-25, right? Technically, the bug seems to be present >>> in 24.5 and earlier, though I can only trigger it in 25.1. >> >> Yes, please push to emacs-25. The bug is sufficiently nasty and the >> solution simple enough to justify that. > > I've pushed as ad66b3fa. -- Best regards, Sam [-- Attachment #2.2: signature.asc --] [-- Type: application/pgp-signature, Size: 162 bytes --] ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-22 21:54 ` Sam Halliday @ 2016-10-22 22:46 ` npostavs 2016-10-23 6:41 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-22 22:46 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358 Sam Halliday <sam.halliday@gmail.com> writes: > when I build emacs-25 with this patch (either by building emacs-25 > directly or taking emacs-25.1 and applying this patch) I get a failure > in make: > > ./autogen.sh > CFLAGS='-O0 -g3 -gdwarf-4' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type --prefix=/opt/emacs25 > make > > . > . > . > make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/admin/grammars' > collected 50% ... > collected 60% ... > collected 70% ... > collected 80% ... > collected 90% ... > Processing OKURI-NASI entries ... > processed 10% ... > processed 20% ... > Args out of range: #("崎/ > かん" 0 5 (charset japanese-jisx0208)), -6, nil > make[2]: *** [Makefile:142: ../lisp/leim/ja-dic/ja-dic.el] Error 255 > make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/leim' > make[1]: *** [Makefile:320: leim] Error 2 > make[1]: Leaving directory '/home/fommil/build/emacs-git/emacs/lisp' > make: *** [Makefile:385: lisp] Error 2 > I can't reproduce this. I did a 'make extraclean' in lisp/leim, and then ran 'make', ja-dic.el was generated without error: GEN ../lisp/leim/ja-dic/ja-dic.el Reading file "/home/npostavs/src/emacs/emacs-25/leim/SKK-DIC/SKK-JISYO.L" ... Processing OKURI-ARI entries ... Processing POSTFIX entries ... Processing PREFIX entries ... Collecting OKURI-NASI entries ... collected 26% ... collected 30% ... collected 40% ... collected 50% ... collected 60% ... collected 70% ... collected 80% ... collected 90% ... Processing OKURI-NASI entries ... processed 10% ... processed 20% ... processed 30% ... processed 40% ... processed 50% ... processed 60% ... processed 70% ... processed 80% ... processed 90% ... processed 100% ... make[2]: Leaving directory '/home/npostavs/src/emacs/emacs-25/leim' ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-22 22:46 ` npostavs @ 2016-10-23 6:41 ` Eli Zaretskii 2016-10-23 8:57 ` Sam Halliday 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 6:41 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: Eli Zaretskii <eliz@gnu.org>, 24358@debbugs.gnu.org > Date: Sat, 22 Oct 2016 18:46:43 -0400 > > Sam Halliday <sam.halliday@gmail.com> writes: > > > Processing OKURI-NASI entries ... > > processed 10% ... > > processed 20% ... > > Args out of range: #("崎/ > > かん" 0 5 (charset japanese-jisx0208)), -6, nil > > make[2]: *** [Makefile:142: ../lisp/leim/ja-dic/ja-dic.el] Error 255 > > make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/leim' > > make[1]: *** [Makefile:320: leim] Error 2 > > make[1]: Leaving directory '/home/fommil/build/emacs-git/emacs/lisp' > > make: *** [Makefile:385: lisp] Error 2 > > > > I can't reproduce this. Neither can I. Sam, does your build use ralloc.c? Also, are you sure this change causes the problem? Note that Paul pushed a follow-up change after that: do you have it in your tree? > I did a 'make extraclean' in lisp/leim, and > then ran 'make', ja-dic.el was generated without error: Sam, please run the failed command under GDB, put a breakpoint in args_out_of_range, and show the C and Lisp backtrace when this error happens. (If args_out_of_range is called more than once, then please make sure you are showing the correct instance, e.g. by looking at the "processed NN%" lines.) ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 6:41 ` Eli Zaretskii @ 2016-10-23 8:57 ` Sam Halliday 2016-10-23 9:19 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 8:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs I don't know which alloc my build is using, I'm on archlinux and I expect it will use the same impl that was causing the problems earlier in the thread. I also got the problem on the tip of emacs-25, but it's hard for me to see which commits are relevant to this ticket because they've all been squashed into the mainline instead of merged in. I'm afraid I'm travelling today and cannot run these commands, I will try to do this shortly. How do I work out the command that make is running? On 23 October 2016 at 07:41, Eli Zaretskii <eliz@gnu.org> wrote: >> From: npostavs@users.sourceforge.net >> Cc: Eli Zaretskii <eliz@gnu.org>, 24358@debbugs.gnu.org >> Date: Sat, 22 Oct 2016 18:46:43 -0400 >> >> Sam Halliday <sam.halliday@gmail.com> writes: >> >> > Processing OKURI-NASI entries ... >> > processed 10% ... >> > processed 20% ... >> > Args out of range: #("崎/ >> > かん" 0 5 (charset japanese-jisx0208)), -6, nil >> > make[2]: *** [Makefile:142: ../lisp/leim/ja-dic/ja-dic.el] Error 255 >> > make[2]: Leaving directory '/home/fommil/build/emacs-git/emacs/leim' >> > make[1]: *** [Makefile:320: leim] Error 2 >> > make[1]: Leaving directory '/home/fommil/build/emacs-git/emacs/lisp' >> > make: *** [Makefile:385: lisp] Error 2 >> > >> >> I can't reproduce this. > > Neither can I. > > Sam, does your build use ralloc.c? Also, are you sure this change > causes the problem? Note that Paul pushed a follow-up change after > that: do you have it in your tree? > >> I did a 'make extraclean' in lisp/leim, and >> then ran 'make', ja-dic.el was generated without error: > > Sam, please run the failed command under GDB, put a breakpoint in > args_out_of_range, and show the C and Lisp backtrace when this error > happens. (If args_out_of_range is called more than once, then please > make sure you are showing the correct instance, e.g. by looking at the > "processed NN%" lines.) ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 8:57 ` Sam Halliday @ 2016-10-23 9:19 ` Eli Zaretskii 2016-10-23 13:40 ` Sam Halliday 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 9:19 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 09:57:21 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > I don't know which alloc my build is using, I'm on archlinux and I > expect it will use the same impl that was causing the problems earlier > in the thread. Do you have ralloc.o in src/? If you do, you are using ralloc.c. > I'm afraid I'm travelling today and cannot run these commands, I will > try to do this shortly. How do I work out the command that make is > running? Like this: cd leim make V=1 This will show the command which creates ja-dic/ja-dic.el. (You can also see it in leim/Makefile.) Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 9:19 ` Eli Zaretskii @ 2016-10-23 13:40 ` Sam Halliday 2016-10-23 14:07 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 13:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs ralloc.c is in "src". Running the failing command, the breakpoint didn't take... must be something else. EMACSLOADPATH= gdb ../src/emacs GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ../src/emacs...done. (gdb) break args_out_of_range Breakpoint 1 at 0x614cc1: file data.c, line 163. (gdb) run -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" Starting program: /home/fommil/build/emacs-git/emacs/src/emacs -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe72e5700 (LWP 14444)] Reading file "/home/fommil/build/emacs-git/emacs/leim/SKK-DIC/SKK-JISYO.L" ... Processing OKURI-ARI entries ... Processing POSTFIX entries ... Processing PREFIX entries ... Collecting OKURI-NASI entries ... collected 26% ... collected 30% ... collected 40% ... collected 50% ... collected 60% ... collected 70% ... collected 80% ... collected 90% ... Processing OKURI-NASI entries ... processed 10% ... processed 20% ... processed 30% ... processed 40% ... Args out of range: #("七宝焼/" 0 4 (charset japanese-jisx0208)), -5, nil [Thread 0x7ffff7f246c0 (LWP 14440) exited] [Inferior 1 (process 14440) exited with code 0377] (gdb) On 23 October 2016 at 10:19, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Sam Halliday <sam.halliday@gmail.com> >> Date: Sun, 23 Oct 2016 09:57:21 +0100 >> Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org >> >> I don't know which alloc my build is using, I'm on archlinux and I >> expect it will use the same impl that was causing the problems earlier >> in the thread. > > Do you have ralloc.o in src/? If you do, you are using ralloc.c. > >> I'm afraid I'm travelling today and cannot run these commands, I will >> try to do this shortly. How do I work out the command that make is >> running? > > Like this: > > cd leim > make V=1 > > This will show the command which creates ja-dic/ja-dic.el. (You can > also see it in leim/Makefile.) > > Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 13:40 ` Sam Halliday @ 2016-10-23 14:07 ` Eli Zaretskii 2016-10-23 15:42 ` Sam Halliday 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 14:07 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 14:40:26 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > ralloc.c is in "src". What about ralloc.o? > Running the failing command, the breakpoint didn't take... must be > something else. Probably some code calls 'signal' or 'error' directly. A breakpoint in Fsignal should catch that. Unfortunately, it could trigger many times before, so if that happens, let me know if you need help in making the breakpoint more selective. > Processing OKURI-NASI entries ... > processed 10% ... > processed 20% ... > processed 30% ... > processed 40% ... > Args out of range: #("七宝焼/" 0 4 (charset japanese-jisx0208)), -5, nil Note that the error is slightly different now (a different string and the argument is -5 instead of -6), and also in a slightly different place of the build (after 40% instead of 20%). ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 14:07 ` Eli Zaretskii @ 2016-10-23 15:42 ` Sam Halliday 2016-10-23 15:48 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 15:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs On 23 October 2016 at 15:07, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Sam Halliday <sam.halliday@gmail.com> >> >> ralloc.c is in "src". > > What about ralloc.o? yes ralloc.o is there, and of course this is what I should have looked for before because ralloc.c is clearly version controlled, sorry! :-) >> Running the failing command, the breakpoint didn't take... must be >> something else. > > Probably some code calls 'signal' or 'error' directly. A breakpoint > in Fsignal should catch that. Unfortunately, it could trigger many > times before, so if that happens, let me know if you need help in > making the breakpoint more selective. > >> Processing OKURI-NASI entries ... >> processed 10% ... >> processed 20% ... >> processed 30% ... >> processed 40% ... >> Args out of range: #("七宝焼/" 0 4 (charset japanese-jisx0208)), -5, nil > > Note that the error is slightly different now (a different string and > the argument is -5 instead of -6), and also in a slightly different > place of the build (after 40% instead of 20%). breaking on Fsignal is hitting the problem... not sure what to do here. I can type "bt" but that's where my gdb skillz end... do you want me to do anything else or is this enough? I'd imagine seeing the contents of error_symbol and data would be pretty useful. I'm not sure the etc/DEBUG .gdbinit file is being loaded properly when invoked from the leim directory. EMACSLOADPATH= gdb ../src/emacs GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ../src/emacs...done. (gdb) break Fsignal Breakpoint 1 at 0x634e00: file eval.c, line 1476. (gdb) run -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" Starting program: /home/fommil/build/emacs-git/emacs/src/emacs -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe72e5700 (LWP 21567)] Reading file "/home/fommil/build/emacs-git/emacs/leim/SKK-DIC/SKK-JISYO.L" ... Processing OKURI-ARI entries ... Processing POSTFIX entries ... Processing PREFIX entries ... Collecting OKURI-NASI entries ... collected 26% ... collected 30% ... collected 40% ... collected 50% ... collected 60% ... collected 70% ... collected 80% ... collected 90% ... Processing OKURI-NASI entries ... processed 10% ... processed 20% ... processed 30% ... processed 40% ... Thread 1 "emacs" hit Breakpoint 1, Fsignal (error_symbol=..., data=...) at eval.c:1476 1476 = (NILP (error_symbol) ? Fcar (data) : error_symbol); (gdb) bt #0 0x0000000000634e00 in Fsignal (error_symbol=..., data=...) at eval.c:1476 #1 0x00000000006351d9 in xsignal (error_symbol=..., data=...) at eval.c:1582 #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., arg2=..., arg3=...) at eval.c:1609 #3 0x0000000000614d16 in args_out_of_range_3 (a1=..., a2=..., a3=...) at data.c:169 #4 0x000000000063f687 in validate_subarray (array=..., from=..., to=..., size=4, ifrom=0x7fffffff6e18, ito=0x7fffffff6e10) at fns.c:1210 #5 0x000000000063f70c in Fsubstring (string=..., from=..., to=...) at fns.c:1235 #6 0x0000000000636da4 in eval_sub (form=...) at eval.c:2177 #7 0x0000000000636c98 in eval_sub (form=...) at eval.c:2159 #8 0x0000000000631bb4 in Fif (args=...) at eval.c:385 #9 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #10 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #11 0x0000000000633be9 in Fwhile (args=...) at eval.c:970 #12 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #13 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #14 0x0000000000633fb0 in internal_catch (tag=..., func=0x631e2e <Fprogn>, arg=...) at eval.c:1079 #15 0x0000000000633f64 in Fcatch (args=...) at eval.c:1056 #16 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #17 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #18 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #19 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #20 0x0000000000631afc in Fand (args=...) at eval.c:366 #21 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #22 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #23 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #24 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #25 0x0000000000631afc in Fand (args=...) at eval.c:366 #26 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #27 0x0000000000631a31 in For (args=...) at eval.c:346 #28 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #29 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #30 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #31 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #32 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #33 0x0000000000639184 in funcall_lambda (fun=..., nargs=5, arg_vector=0x0) at eval.c:2921 #34 0x00000000006389cd in apply_lambda (fun=..., args=..., count=77) at eval.c:2799 #35 0x0000000000637145 in eval_sub (form=...) at eval.c:2246 #36 0x0000000000631a31 in For (args=...) at eval.c:346 #37 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #38 0x0000000000631afc in Fand (args=...) at eval.c:366 #39 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #40 0x0000000000631a31 in For (args=...) at eval.c:346 #41 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #42 0x0000000000631bb4 in Fif (args=...) at eval.c:385 #43 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #44 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #45 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #46 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #47 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #48 0x0000000000633be9 in Fwhile (args=...) at eval.c:970 #49 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #50 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #51 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #52 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #53 0x0000000000631afc in Fand (args=...) at eval.c:366 #54 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #55 0x0000000000631a31 in For (args=...) at eval.c:346 #56 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #57 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #58 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #59 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #60 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #61 0x0000000000639184 in funcall_lambda (fun=..., nargs=6, arg_vector=0x0) at eval.c:2921 #62 0x00000000006389cd in apply_lambda (fun=..., args=..., count=55) at eval.c:2799 #63 0x0000000000637145 in eval_sub (form=...) at eval.c:2246 #64 0x0000000000636c98 in eval_sub (form=...) at eval.c:2159 #65 0x0000000000631afc in Fand (args=...) at eval.c:366 #66 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #67 0x0000000000631a31 in For (args=...) at eval.c:346 #68 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #69 0x0000000000631bb4 in Fif (args=...) at eval.c:385 #70 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #71 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #72 0x0000000000633be9 in Fwhile (args=...) at eval.c:970 #73 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #74 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #75 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #76 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #77 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #78 0x0000000000639184 in funcall_lambda (fun=..., nargs=3, arg_vector=0x0) at eval.c:2921 #79 0x00000000006389cd in apply_lambda (fun=..., args=..., count=43) at eval.c:2799 #80 0x0000000000637145 in eval_sub (form=...) at eval.c:2246 #81 0x0000000000632122 in Fsetq (args=...) at eval.c:502 #82 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #83 0x0000000000631bb4 in Fif (args=...) at eval.c:385 #84 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #85 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #86 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #87 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #88 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #89 0x0000000000633be9 in Fwhile (args=...) at eval.c:970 #90 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #91 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #92 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #93 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #94 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #95 0x0000000000622ec9 in Fsave_current_buffer (args=...) at editfns.c:1027 #96 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #97 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #98 0x0000000000639184 in funcall_lambda (fun=..., nargs=2, arg_vector=0x0) at eval.c:2921 #99 0x00000000006389cd in apply_lambda (fun=..., args=..., count=27) at eval.c:2799 #100 0x0000000000637145 in eval_sub (form=...) at eval.c:2246 #101 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #102 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #103 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #104 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #105 0x0000000000622ec9 in Fsave_current_buffer (args=...) at editfns.c:1027 #106 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #107 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #108 0x0000000000633566 in FletX (args=...) at eval.c:887 #109 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #110 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #111 0x0000000000639184 in funcall_lambda (fun=..., nargs=2, arg_vector=0x0) at eval.c:2921 #112 0x00000000006389cd in apply_lambda (fun=..., args=..., count=15) at eval.c:2799 #113 0x0000000000637145 in eval_sub (form=...) at eval.c:2246 #114 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #115 0x0000000000633ad3 in Flet (args=...) at eval.c:951 #116 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #117 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #118 0x0000000000631cbc in Fif (args=...) at eval.c:389 #119 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #120 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 #121 0x0000000000639184 in funcall_lambda (fun=..., nargs=0, arg_vector=0x0) at eval.c:2921 #122 0x000000000063875e in Ffuncall (nargs=1, args=0x7fffffffc6e0) at eval.c:2759 #123 0x0000000000683e8a in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffcf88) at bytecode.c:880 #124 0x0000000000638d80 in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffcf80) at eval.c:2862 #125 0x0000000000638659 in Ffuncall (nargs=2, args=0x7fffffffcf78) at eval.c:2747 #126 0x0000000000683e8a in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffd878) at bytecode.c:880 #127 0x0000000000638d80 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffd878) at eval.c:2862 #128 0x0000000000638659 in Ffuncall (nargs=1, args=0x7fffffffd870) at eval.c:2747 #129 0x0000000000683e8a in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffe040) at bytecode.c:880 #130 0x0000000000638d80 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffe040) at eval.c:2862 #131 0x00000000006389cd in apply_lambda (fun=..., args=..., count=4) at eval.c:2799 #132 0x0000000000636f3e in eval_sub (form=...) at eval.c:2216 #133 0x00000000006363f8 in Feval (form=..., lexical=...) at eval.c:1993 #134 0x0000000000587ce2 in top_level_2 () at keyboard.c:1121 #135 0x00000000006349f6 in internal_condition_case (bfun=0x587cc5 <top_level_2>, handlers=..., hfun=0x5876f3 <cmd_error>) at eval.c:1314 #136 0x0000000000587d23 in top_level_1 (ignore=...) at keyboard.c:1129 #137 0x0000000000633fb0 in internal_catch (tag=..., func=0x587ce4 <top_level_1>, arg=...) at eval.c:1079 #138 0x0000000000587c1d in command_loop () at keyboard.c:1090 #139 0x00000000005871f5 in recursive_edit_1 () at keyboard.c:697 #140 0x00000000005873ec in Frecursive_edit () at keyboard.c:768 #141 0x0000000000585152 in main (argc=11, argv=0x7fffffffe5d8) at emacs.c:1626 ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 15:42 ` Sam Halliday @ 2016-10-23 15:48 ` Eli Zaretskii 2016-10-23 15:58 ` Sam Halliday 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 15:48 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 16:42:20 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > breaking on Fsignal is hitting the problem... not sure what to do > here. I can type "bt" but that's where my gdb skillz end... do you > want me to do anything else or is this enough? "bt" is a good start, thanks. After that, the results of "xbacktrace" will help more. > I'd imagine seeing the contents of error_symbol and data would be > pretty useful. I'm not sure the etc/DEBUG .gdbinit file is being > loaded properly when invoked from the leim directory. You can read .gdbinit manually: (gdb) source ../src/.gdbinit And yes, making sure error_symbol and data are as we expect them would be a good start. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 15:48 ` Eli Zaretskii @ 2016-10-23 15:58 ` Sam Halliday 2016-10-23 15:58 ` Sam Halliday 2016-10-23 17:19 ` Eli Zaretskii 0 siblings, 2 replies; 76+ messages in thread From: Sam Halliday @ 2016-10-23 15:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs ok, that worked to source the .gdbinit and xbacktrace works now... (this is a fresh session). I don't know how to print out the parameters to this function. I tried "info" (see below) but it's still giving ... EMACSLOADPATH= gdb ../src/emacs GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ../src/emacs...done. (gdb) break Fsigna Function "Fsigna" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (Fsigna) pending. (gdb) break Fsignal Breakpoint 2 at 0x634e00: file eval.c, line 1476. (gdb) source ../src/.gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0 TERM = rxvt-unicode-256color Breakpoint 3 at 0x583686: file emacs.c, line 354. Temporary breakpoint 4 at 0x5ae0bc: file sysdep.c, line 915. (gdb) run -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" Starting program: /home/fommil/build/emacs-git/emacs/src/emacs -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" "SKK-DIC/SKK-JISYO.L" [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe72e5700 (LWP 24197)] Reading file "/home/fommil/build/emacs-git/emacs/leim/SKK-DIC/SKK-JISYO.L" ... Processing OKURI-ARI entries ... Processing POSTFIX entries ... Processing PREFIX entries ... Collecting OKURI-NASI entries ... collected 26% ... collected 30% ... collected 40% ... collected 50% ... collected 60% ... collected 70% ... collected 80% ... collected 90% ... Processing OKURI-NASI entries ... processed 10% ... processed 20% ... processed 30% ... processed 40% ... Thread 1 "emacs" hit Breakpoint 2, Fsignal (error_symbol=..., data=...) at eval.c:1476 1476 = (NILP (error_symbol) ? Fcar (data) : error_symbol); (gdb) xbacktrace "substring" (0xffff6f00) "string=" (0xffff70a0) "if" (0xffff7230) "while" (0xffff7400) "catch" (0xffff7600) "let" (0xffff7860) "and" (0xffff79f0) "let" (0xffff7c50) "and" (0xffff7de0) "or" (0xffff7f70) "let" (0xffff81d0) "skkdic-breakup-string" (0xffff8380) "or" (0xffff8690) "and" (0xffff8820) "or" (0xffff89b0) "if" (0xffff8b40) "let" (0xffff8da0) "while" (0xffff8f70) "let" (0xffff91e0) "and" (0xffff9370) "or" (0xffff9500) "let" (0xffff9760) "skkdic-breakup-string" (0xffff9910) "not" (0xffff9be0) "and" (0xffff9d70) "or" (0xffff9f00) "if" (0xffffa090) "while" (0xffffa260) "let" (0xffffa4c0) "skkdic-reduced-candidates" (0xffffa670) "setq" (0xffffa9b0) "if" (0xffffab40) "let" (0xffffada0) "while" (0xffffaf70) "let" (0xffffb1e0) "save-current-buffer" (0xffffb390) "skkdic-convert-okuri-nasi" (0xffffb540) "let" (0xffffb900) "save-current-buffer" (0xffffbab0) "let*" (0xffffbcc0) "skkdic-convert" (0xffffbe70) "let" (0xffffc230) "if" (0xffffc3f0) "batch-skkdic-convert" (0xffffc6e8) "command-line-1" (0xffffcf80) "command-line" (0xffffd878) "normal-top-level" (0xffffe040) (gdb) bt #0 0x0000000000634e00 in Fsignal (error_symbol=..., data=...) at eval.c:1476 #1 0x00000000006351d9 in xsignal (error_symbol=..., data=...) at eval.c:1582 #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., arg2=..., arg3=...) at eval.c:1609 #3 0x0000000000614d16 in args_out_of_range_3 (a1=..., a2=..., a3=...) at data.c:169 #4 0x000000000063f687 in validate_subarray (array=..., from=..., to=..., size=4, ifrom=0x7fffffff6e18, ito=0x7fffffff6e10) at fns.c:1210 #5 0x000000000063f70c in Fsubstring (string=..., from=..., to=...) at fns.c:1235 #6 0x0000000000636da4 in eval_sub (form=...) at eval.c:2177 #7 0x0000000000636c98 in eval_sub (form=...) at eval.c:2159 #8 0x0000000000631bb4 in Fif (args=...) at eval.c:385 #9 0x00000000006369df in eval_sub (form=...) at eval.c:2124 #10 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 (gdb) info f Stack level 1, frame at 0x7fffffff6cf0: rip = 0x6351d9 in xsignal (eval.c:1582); saved rip = 0x6352ae called by frame at 0x7fffffff6d40, caller of frame at 0x7fffffff6cc0 source language c. Arglist at 0x7fffffff6ce0, args: error_symbol=..., data=... Locals at 0x7fffffff6ce0, Previous frame's sp is 0x7fffffff6cf0 Saved registers: rbp at 0x7fffffff6ce0, rip at 0x7fffffff6ce8 On 23 October 2016 at 16:48, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Sam Halliday <sam.halliday@gmail.com> >> Date: Sun, 23 Oct 2016 16:42:20 +0100 >> Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org >> >> breaking on Fsignal is hitting the problem... not sure what to do >> here. I can type "bt" but that's where my gdb skillz end... do you >> want me to do anything else or is this enough? > > "bt" is a good start, thanks. After that, the results of "xbacktrace" > will help more. > >> I'd imagine seeing the contents of error_symbol and data would be >> pretty useful. I'm not sure the etc/DEBUG .gdbinit file is being >> loaded properly when invoked from the leim directory. > > You can read .gdbinit manually: > > (gdb) source ../src/.gdbinit > > And yes, making sure error_symbol and data are as we expect them would > be a good start. > > Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 15:58 ` Sam Halliday @ 2016-10-23 15:58 ` Sam Halliday 2016-10-23 16:44 ` Eli Zaretskii 2016-10-23 17:19 ` Eli Zaretskii 1 sibling, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 15:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs aha! Found out how to print the args (gdb) info args error_symbol = { i = 9600 } data = { i = 116316307 } (gdb) f 2 #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., arg2=..., arg3=...) at eval.c:1609 1609 xsignal (error_symbol, list3 (arg1, arg2, arg3)); (gdb) info args error_symbol = { i = 9600 } arg1 = { i = 63960004 } arg2 = { i = -18 } arg3 = { i = 0 } On 23 October 2016 at 16:58, Sam Halliday <sam.halliday@gmail.com> wrote: > ok, that worked to source the .gdbinit and xbacktrace works now... > (this is a fresh session). > > I don't know how to print out the parameters to this function. I tried > "info" (see below) but it's still giving ... > > > EMACSLOADPATH= gdb ../src/emacs > GNU gdb (GDB) 7.12 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ../src/emacs...done. > (gdb) break Fsigna > Function "Fsigna" not defined. > Make breakpoint pending on future shared library load? (y or [n]) y > Breakpoint 1 (Fsigna) pending. > (gdb) break Fsignal > Breakpoint 2 at 0x634e00: file eval.c, line 1476. > (gdb) source ../src/.gdbinit > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not > from terminal] > DISPLAY = :0 > TERM = rxvt-unicode-256color > Breakpoint 3 at 0x583686: file emacs.c, line 354. > Temporary breakpoint 4 at 0x5ae0bc: file sysdep.c, line 915. > (gdb) run -batch --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f > batch-skkdic-convert -dir "./../lisp/leim/ja-dic" > "SKK-DIC/SKK-JISYO.L" > Starting program: /home/fommil/build/emacs-git/emacs/src/emacs -batch > --no-site-file --no-site-lisp -batch -l ja-dic-cnv -f > batch-skkdic-convert -dir "./../lisp/leim/ja-dic" > "SKK-DIC/SKK-JISYO.L" > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > [New Thread 0x7fffe72e5700 (LWP 24197)] > Reading file "/home/fommil/build/emacs-git/emacs/leim/SKK-DIC/SKK-JISYO.L" ... > Processing OKURI-ARI entries ... > Processing POSTFIX entries ... > Processing PREFIX entries ... > Collecting OKURI-NASI entries ... > collected 26% ... > collected 30% ... > collected 40% ... > collected 50% ... > collected 60% ... > collected 70% ... > collected 80% ... > collected 90% ... > Processing OKURI-NASI entries ... > processed 10% ... > processed 20% ... > processed 30% ... > processed 40% ... > > Thread 1 "emacs" hit Breakpoint 2, Fsignal (error_symbol=..., > data=...) at eval.c:1476 > 1476 = (NILP (error_symbol) ? Fcar (data) : error_symbol); > (gdb) xbacktrace > "substring" (0xffff6f00) > "string=" (0xffff70a0) > "if" (0xffff7230) > "while" (0xffff7400) > "catch" (0xffff7600) > "let" (0xffff7860) > "and" (0xffff79f0) > "let" (0xffff7c50) > "and" (0xffff7de0) > "or" (0xffff7f70) > "let" (0xffff81d0) > "skkdic-breakup-string" (0xffff8380) > "or" (0xffff8690) > "and" (0xffff8820) > "or" (0xffff89b0) > "if" (0xffff8b40) > "let" (0xffff8da0) > "while" (0xffff8f70) > "let" (0xffff91e0) > "and" (0xffff9370) > "or" (0xffff9500) > "let" (0xffff9760) > "skkdic-breakup-string" (0xffff9910) > "not" (0xffff9be0) > "and" (0xffff9d70) > "or" (0xffff9f00) > "if" (0xffffa090) > "while" (0xffffa260) > "let" (0xffffa4c0) > "skkdic-reduced-candidates" (0xffffa670) > "setq" (0xffffa9b0) > "if" (0xffffab40) > "let" (0xffffada0) > "while" (0xffffaf70) > "let" (0xffffb1e0) > "save-current-buffer" (0xffffb390) > "skkdic-convert-okuri-nasi" (0xffffb540) > "let" (0xffffb900) > "save-current-buffer" (0xffffbab0) > "let*" (0xffffbcc0) > "skkdic-convert" (0xffffbe70) > "let" (0xffffc230) > "if" (0xffffc3f0) > "batch-skkdic-convert" (0xffffc6e8) > "command-line-1" (0xffffcf80) > "command-line" (0xffffd878) > "normal-top-level" (0xffffe040) > > (gdb) bt > #0 0x0000000000634e00 in Fsignal (error_symbol=..., data=...) at eval.c:1476 > #1 0x00000000006351d9 in xsignal (error_symbol=..., data=...) at eval.c:1582 > #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., > arg2=..., arg3=...) at eval.c:1609 > #3 0x0000000000614d16 in args_out_of_range_3 (a1=..., a2=..., a3=...) > at data.c:169 > #4 0x000000000063f687 in validate_subarray (array=..., from=..., > to=..., size=4, ifrom=0x7fffffff6e18, ito=0x7fffffff6e10) at > fns.c:1210 > #5 0x000000000063f70c in Fsubstring (string=..., from=..., to=...) at > fns.c:1235 > #6 0x0000000000636da4 in eval_sub (form=...) at eval.c:2177 > #7 0x0000000000636c98 in eval_sub (form=...) at eval.c:2159 > #8 0x0000000000631bb4 in Fif (args=...) at eval.c:385 > #9 0x00000000006369df in eval_sub (form=...) at eval.c:2124 > #10 0x0000000000631e85 in Fprogn (body=...) at eval.c:431 > > (gdb) info f > Stack level 1, frame at 0x7fffffff6cf0: > rip = 0x6351d9 in xsignal (eval.c:1582); saved rip = 0x6352ae > called by frame at 0x7fffffff6d40, caller of frame at 0x7fffffff6cc0 > source language c. > Arglist at 0x7fffffff6ce0, args: error_symbol=..., data=... > Locals at 0x7fffffff6ce0, Previous frame's sp is 0x7fffffff6cf0 > Saved registers: > rbp at 0x7fffffff6ce0, rip at 0x7fffffff6ce8 > > > On 23 October 2016 at 16:48, Eli Zaretskii <eliz@gnu.org> wrote: >>> From: Sam Halliday <sam.halliday@gmail.com> >>> Date: Sun, 23 Oct 2016 16:42:20 +0100 >>> Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org >>> >>> breaking on Fsignal is hitting the problem... not sure what to do >>> here. I can type "bt" but that's where my gdb skillz end... do you >>> want me to do anything else or is this enough? >> >> "bt" is a good start, thanks. After that, the results of "xbacktrace" >> will help more. >> >>> I'd imagine seeing the contents of error_symbol and data would be >>> pretty useful. I'm not sure the etc/DEBUG .gdbinit file is being >>> loaded properly when invoked from the leim directory. >> >> You can read .gdbinit manually: >> >> (gdb) source ../src/.gdbinit >> >> And yes, making sure error_symbol and data are as we expect them would >> be a good start. >> >> Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 15:58 ` Sam Halliday @ 2016-10-23 16:44 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 16:44 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 16:58:59 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > aha! Found out how to print the args > > (gdb) info args > error_symbol = { > i = 9600 > } > data = { > i = 116316307 > } > > (gdb) f 2 > #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., > arg2=..., arg3=...) at eval.c:1609 > 1609 xsignal (error_symbol, list3 (arg1, arg2, arg3)); > (gdb) info args > error_symbol = { > i = 9600 > } > arg1 = { > i = 63960004 > } > arg2 = { > i = -18 > } > arg3 = { > i = 0 > } Something like (gdb) p arg1 (gdb) xpr will show a human-readable description of the Lisp objects. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 15:58 ` Sam Halliday 2016-10-23 15:58 ` Sam Halliday @ 2016-10-23 17:19 ` Eli Zaretskii 2016-10-23 18:06 ` Eli Zaretskii 2016-10-23 18:11 ` Sam Halliday 1 sibling, 2 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 17:19 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 16:58:07 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > Processing OKURI-NASI entries ... > processed 10% ... > processed 20% ... > processed 30% ... > processed 40% ... > > Thread 1 "emacs" hit Breakpoint 2, Fsignal (error_symbol=..., > data=...) at eval.c:1476 > 1476 = (NILP (error_symbol) ? Fcar (data) : error_symbol); > (gdb) xbacktrace > "substring" (0xffff6f00) > "string=" (0xffff70a0) > "if" (0xffff7230) > "while" (0xffff7400) > "catch" (0xffff7600) > "let" (0xffff7860) > "and" (0xffff79f0) > "let" (0xffff7c50) > "and" (0xffff7de0) > "or" (0xffff7f70) > "let" (0xffff81d0) > "skkdic-breakup-string" (0xffff8380) Thanks. Does it help to delete this line: re_match_object = Qnil; /* Stop protecting string from GC. */ in src/search.c:string_match_1 (should be line 404)? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 17:19 ` Eli Zaretskii @ 2016-10-23 18:06 ` Eli Zaretskii 2016-10-23 18:14 ` Noam Postavsky 2016-10-23 18:16 ` Sam Halliday 2016-10-23 18:11 ` Sam Halliday 1 sibling, 2 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 18:06 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 Noam, I think we need these two changes, because otherwise looping more than once in search_buffer will fail to update the pointers passed to re_search_2, if buffer text was relocated inside re_search_2. Do you agree? diff --git a/src/search.c b/src/search.c index ec5a1d7..5c04916 100644 --- a/src/search.c +++ b/src/search.c @@ -1233,6 +1233,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, ? &search_regs : &search_regs_1), /* Don't allow match past current point */ pos_byte - BEGV_BYTE); + /* Update 'base' due to possible relocation inside re_search_2. */ + base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); @@ -1279,6 +1281,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); + /* Update 'base' due to possible relocation inside re_search_2. */ + base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 18:06 ` Eli Zaretskii @ 2016-10-23 18:14 ` Noam Postavsky 2016-10-23 19:18 ` Eli Zaretskii 2016-10-23 18:16 ` Sam Halliday 1 sibling, 1 reply; 76+ messages in thread From: Noam Postavsky @ 2016-10-23 18:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Sam Halliday, 24358 On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <eliz@gnu.org> wrote: > Noam, I think we need these two changes, because otherwise looping > more than once in search_buffer will fail to update the pointers > passed to re_search_2, if buffer text was relocated inside > re_search_2. > > Do you agree? Ack, yes! Missing the update to base was a total thinko on my part. > > diff --git a/src/search.c b/src/search.c > index ec5a1d7..5c04916 100644 > --- a/src/search.c > +++ b/src/search.c > @@ -1233,6 +1233,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > ? &search_regs : &search_regs_1), > /* Don't allow match past current point */ > pos_byte - BEGV_BYTE); > + /* Update 'base' due to possible relocation inside re_search_2. */ > + base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); > @@ -1279,6 +1281,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : &search_regs_1), > lim_byte - BEGV_BYTE); > + /* Update 'base' due to possible relocation inside re_search_2. */ > + base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 18:14 ` Noam Postavsky @ 2016-10-23 19:18 ` Eli Zaretskii 2016-10-24 13:29 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 19:18 UTC (permalink / raw) To: Noam Postavsky; +Cc: sam.halliday, 24358 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sun, 23 Oct 2016 14:14:59 -0400 > Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org > > On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Noam, I think we need these two changes, because otherwise looping > > more than once in search_buffer will fail to update the pointers > > passed to re_search_2, if buffer text was relocated inside > > re_search_2. > > > > Do you agree? > > Ack, yes! Missing the update to base was a total thinko on my part. Pushed. There might be a more serious problem with this, unfortunately: the search registers are computed in regex.c using pointers into the C strings that are being searched. The general paradigm is as in this fragment: regstart[*p] = d; [...] regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is consistent with the current base address of the string into which it points. Did you study this aspect of regex.c when you decided which values need to be affected by relocation? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 19:18 ` Eli Zaretskii @ 2016-10-24 13:29 ` npostavs 2016-10-24 13:39 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 76+ messages in thread From: npostavs @ 2016-10-24 13:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 I was able to reproduce the failure in ja-dic-cnv after removing --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no --with-jpeg=no from my configure args (I guess using GTK changes the allocation patterns), and doing 'make extraclean'. The error went away after I updated to the latest emacs-25 commit: ee04aedc72 "Fix handling of buffer relocation in regex.c functions". The error occurs in the commit just before it 71ca4f6a "Avoid relocating buffers while libxml2 reads its text", so I think Eli's fix for the base pointer in search_buffer does solve the problem. Sam, can you confirm if this fixes it for you? Eli Zaretskii <eliz@gnu.org> writes: >> From: Noam Postavsky <npostavs@users.sourceforge.net> >> Date: Sun, 23 Oct 2016 14:14:59 -0400 >> Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org >> >> On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> > Noam, I think we need these two changes, because otherwise looping >> > more than once in search_buffer will fail to update the pointers >> > passed to re_search_2, if buffer text was relocated inside >> > re_search_2. >> > >> > Do you agree? >> >> Ack, yes! Missing the update to base was a total thinko on my part. > > Pushed. > > There might be a more serious problem with this, unfortunately: the > search registers are computed in regex.c using pointers into the C > strings that are being searched. The general paradigm is as in this > fragment: > > regstart[*p] = d; > [...] > regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); > > POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is > consistent with the current base address of the string into which it > points. Did you study this aspect of regex.c when you decided which > values need to be affected by relocation? I did not look at that before, but looking now, I don't see why it would be a problem. I put the base address updating code around the only place where malloc may be called, so string1 and string2 (which POINTER_TO_OFFSET uses) should always be consistent with the base address (unless there is some other malloc call that I missed?). ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 13:29 ` npostavs @ 2016-10-24 13:39 ` Eli Zaretskii 2016-10-24 15:33 ` Noam Postavsky 2016-10-24 13:43 ` Eli Zaretskii 2016-10-24 20:13 ` Sam Halliday 2 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 13:39 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Mon, 24 Oct 2016 09:29:21 -0400 > > > regstart[*p] = d; > > [...] > > regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); > > > > POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is > > consistent with the current base address of the string into which it > > points. Did you study this aspect of regex.c when you decided which > > values need to be affected by relocation? > > I did not look at that before, but looking now, I don't see why it would > be a problem. I put the base address updating code around the only > place where malloc may be called, so string1 and string2 (which > POINTER_TO_OFFSET uses) should always be consistent with the base > address (unless there is some other malloc call that I missed?). What bothers me is this: could it be that relocation happens between the first and the second line above? If it can, then what POINTER_TO_OFFSET does will be inconsistent with the base address at the time regstart[*p] was assigned the value of d. The code runs in a loop, or so it seems, so it's hard to reason about time sequences. But I'm not saying I clearly see a problem, just that I fear there might be one. If your reading of the code is that it cannot happen, I'm happy. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 13:39 ` Eli Zaretskii @ 2016-10-24 15:33 ` Noam Postavsky 2016-10-24 16:13 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Noam Postavsky @ 2016-10-24 15:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Sam Halliday, 24358 On Mon, Oct 24, 2016 at 9:39 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com >> Date: Mon, 24 Oct 2016 09:29:21 -0400 >> >> > regstart[*p] = d; >> > [...] >> > regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); >> > >> > POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is >> > consistent with the current base address of the string into which it >> > points. Did you study this aspect of regex.c when you decided which >> > values need to be affected by relocation? >> >> I did not look at that before, but looking now, I don't see why it would >> be a problem. I put the base address updating code around the only >> place where malloc may be called, so string1 and string2 (which >> POINTER_TO_OFFSET uses) should always be consistent with the base >> address (unless there is some other malloc call that I missed?). > > What bothers me is this: could it be that relocation happens between > the first and the second line above? If it can, then what > POINTER_TO_OFFSET does will be inconsistent with the base address at > the time regstart[*p] was assigned the value of d. > > The code runs in a loop, or so it seems, so it's hard to reason about > time sequences. Oh, I see. Yes, I think you're right, the pointers stored in regstart, regend, and fail_stack could become inconsistent. Hard to say what kind of regex could trigger it, but it seems quite possible. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 15:33 ` Noam Postavsky @ 2016-10-24 16:13 ` Eli Zaretskii 2016-10-25 2:00 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 16:13 UTC (permalink / raw) To: Noam Postavsky; +Cc: sam.halliday, 24358 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Mon, 24 Oct 2016 11:33:11 -0400 > Cc: 24358@debbugs.gnu.org, Sam Halliday <sam.halliday@gmail.com> > > > What bothers me is this: could it be that relocation happens between > > the first and the second line above? If it can, then what > > POINTER_TO_OFFSET does will be inconsistent with the base address at > > the time regstart[*p] was assigned the value of d. > > > > The code runs in a loop, or so it seems, so it's hard to reason about > > time sequences. > > Oh, I see. Yes, I think you're right, the pointers stored in regstart, > regend, and fail_stack could become inconsistent. Hard to say what > kind of regex could trigger it, but it seems quite possible. Maybe we should simply call r_alloc_inhibit_buffer_relocation around any calls to regex.c functions, and remove the code you wrote to handle relocations internally. I'm sorry I didn't look at this closer before, and thus caused you to work on all those changes, which we might now need to revert. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 16:13 ` Eli Zaretskii @ 2016-10-25 2:00 ` npostavs 2016-10-25 16:03 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: npostavs @ 2016-10-25 2:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 [-- Attachment #1: Type: text/plain, Size: 432 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> Oh, I see. Yes, I think you're right, the pointers stored in regstart, >> regend, and fail_stack could become inconsistent. Hard to say what >> kind of regex could trigger it, but it seems quite possible. > > Maybe we should simply call r_alloc_inhibit_buffer_relocation around > any calls to regex.c functions, and remove the code you wrote to > handle relocations internally. How's this: [-- Attachment #2: reverting patch --] [-- Type: text/plain, Size: 12015 bytes --] From c3e87ee1e1399f3687db02dc71b13830852a50eb Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Mon, 24 Oct 2016 19:54:29 -0400 Subject: [PATCH v4 1/2] Revert fixes to allocation of regex matching The fix was not complete, and completing it was proving too complicated. - Revert "* src/regex.c (re_search_2): Make new code safe for -Wjump-misses-init." This reverts commit c2a17924a57483d14692c8913edbe8ad24b5ffbb. - Revert "Port to GCC 6.2.1 + --enable-gcc-warnings" This reverts commit f6134bbda259c115c06d4a9a3ab5c39340a15949. - Revert "Fix handling of allocation in regex matching" This reverts commit ad66b3fadb7ae22a4cbb82bb1507c39ceadf3897. - Revert "Fix handling of buffer relocation in regex.c functions" This reverts commit ee04aedc723b035eedaf975422d4eb242894121b. --- src/dired.c | 4 +--- src/regex.c | 73 ------------------------------------------------------------ src/regex.h | 4 +--- src/search.c | 40 ++++++++++----------------------- 4 files changed, 14 insertions(+), 107 deletions(-) diff --git a/src/dired.c b/src/dired.c index 006f74c..dba575c 100644 --- a/src/dired.c +++ b/src/dired.c @@ -259,11 +259,9 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, QUIT; bool wanted = (NILP (match) - || (re_match_object = name, - re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0)); + || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting name from GC. */ if (wanted) { diff --git a/src/regex.c b/src/regex.c index b12e95b..56b18e6 100644 --- a/src/regex.c +++ b/src/regex.c @@ -1438,62 +1438,11 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer #define TOP_FAILURE_HANDLE() fail_stack.frame -#ifdef emacs -# define STR_BASE_PTR(obj) \ - (NILP (obj) ? current_buffer->text->beg \ - : STRINGP (obj) ? SDATA (obj) \ - : NULL) -#else -# define STR_BASE_PTR(obj) NULL -#endif #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ - re_char *orig_base = STR_BASE_PTR (re_match_object); \ - bool might_relocate = orig_base != NULL; \ - ptrdiff_t string1_off, end1_off, end_match_1_off; \ - ptrdiff_t string2_off, end2_off, end_match_2_off; \ - ptrdiff_t d_off, dend_off, dfail_off; \ - if (might_relocate) \ - { \ - if (string1) \ - { \ - string1_off = string1 - orig_base; \ - end1_off = end1 - orig_base; \ - end_match_1_off = end_match_1 - orig_base; \ - } \ - if (string2) \ - { \ - string2_off = string2 - orig_base; \ - end2_off = end2 - orig_base; \ - end_match_2_off = end_match_2 - orig_base; \ - } \ - d_off = d - orig_base; \ - dend_off = dend - orig_base; \ - dfail_off = dfail - orig_base; \ - } \ if (!GROW_FAIL_STACK (fail_stack)) \ return -2; \ - /* In Emacs, GROW_FAIL_STACK might relocate string pointers. */ \ - if (might_relocate) \ - { \ - re_char *new_base = STR_BASE_PTR (re_match_object); \ - if (string1) \ - { \ - string1 = new_base + string1_off; \ - end1 = new_base + end1_off; \ - end_match_1 = new_base + end_match_1_off; \ - } \ - if (string2) \ - { \ - string2 = new_base + string2_off; \ - end2 = new_base + end2_off; \ - end_match_2 = new_base + end_match_2_off; \ - } \ - d = new_base + d_off; \ - dend = new_base + dend_off; \ - dfail = new_base + dfail_off; \ - } \ DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ } @@ -4380,10 +4329,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, /* Loop through the string, looking for a place to start matching. */ for (;;) { - ptrdiff_t offset1, offset2; - re_char *orig_base; - bool might_relocate; - /* If the pattern is anchored, skip quickly past places we cannot match. We don't bother to treat startpos == 0 specially @@ -4500,17 +4445,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, && !bufp->can_be_null) return -1; - /* re_match_2_internal may allocate, relocating the Lisp text - object that we're searching. */ - IF_LINT (offset2 = 0); /* Work around GCC bug 78081. */ - orig_base = STR_BASE_PTR (re_match_object); - might_relocate = orig_base != NULL; - if (might_relocate) - { - if (string1) offset1 = string1 - orig_base; - if (string2) offset2 = string2 - orig_base; - } - val = re_match_2_internal (bufp, string1, size1, string2, size2, startpos, regs, stop); @@ -4520,13 +4454,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, if (val == -2) return -2; - if (might_relocate) - { - re_char *new_base = STR_BASE_PTR (re_match_object); - if (string1) string1 = offset1 + new_base; - if (string2) string2 = offset2 + new_base; - } - advance: if (!range) break; diff --git a/src/regex.h b/src/regex.h index 61c771c..51f4424 100644 --- a/src/regex.h +++ b/src/regex.h @@ -169,9 +169,7 @@ extern reg_syntax_t re_syntax_options; #ifdef emacs # include "lisp.h" /* In Emacs, this is the string or buffer in which we are matching. - It is used for looking up syntax properties, and also to recompute - pointers in case the object is relocated as a side effect of - calling malloc (if it calls r_alloc_sbrk in ralloc.c). + It is used for looking up syntax properties. If the value is a Lisp string object, we are matching text in that string; if it's nil, we are matching text in the current buffer; if diff --git a/src/search.c b/src/search.c index b50e7f0..fa5ac44 100644 --- a/src/search.c +++ b/src/search.c @@ -287,10 +287,8 @@ looking_at_1 (Lisp_Object string, bool posix) immediate_quit = 1; QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings that make up the - visible portion of the buffer. Note that we can use pointers - here, unlike in search_buffer, because we only call re_match_2 - once, after which we never use the pointers again. */ + /* Get pointers and sizes of the two strings + that make up the visible portion of the buffer. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; @@ -409,7 +407,6 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL)); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ /* Set last_thing_searched only when match data is changed. */ if (NILP (Vinhibit_changing_match_data)) @@ -480,7 +477,6 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, SBYTES (string), 0, SBYTES (string), 0); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ return val; } @@ -568,7 +564,6 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ return len; } @@ -1183,8 +1178,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) { - unsigned char *base; - ptrdiff_t off1, off2, s1, s2; + unsigned char *p1, *p2; + ptrdiff_t s1, s2; struct re_pattern_buffer *bufp; bufp = compile_pattern (string, @@ -1198,19 +1193,16 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, can take too long. */ QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get offsets and sizes of the two strings that make up the - visible portion of the buffer. We compute offsets instead of - pointers because re_search_2 may call malloc and therefore - change the buffer text address. */ + /* Get pointers and sizes of the two strings + that make up the visible portion of the buffer. */ - base = current_buffer->text->beg; - off1 = BEGV_ADDR - base; + p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; - off2 = GAP_END_ADDR - base; + p2 = GAP_END_ADDR; s2 = ZV_BYTE - GPT_BYTE; if (s1 < 0) { - off2 = off1; + p2 = p1; s2 = ZV_BYTE - BEGV_BYTE; s1 = 0; } @@ -1225,16 +1217,12 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, - (char*) (base + off1), s1, - (char*) (base + off2), s2, + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), /* Don't allow match past current point */ pos_byte - BEGV_BYTE); - /* Update 'base' due to possible relocation inside re_search_2. */ - base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); @@ -1274,15 +1262,11 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, - (char*) (base + off1), s1, - (char*) (base + off2), s2, - pos_byte - BEGV_BYTE, lim_byte - pos_byte, + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, + pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); - /* Update 'base' due to possible relocation inside re_search_2. */ - base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); -- 2.9.3 [-- Attachment #3: patch --] [-- Type: text/plain, Size: 2823 bytes --] From 79806c03ad9f45d8ed016a06f5e24cf69df85ad2 Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Mon, 24 Oct 2016 21:22:07 -0400 Subject: [PATCH v4 2/2] Inhibit buffer relocation during regex searches * src/search.c (looking_at_1, fast_looking_at, search_buffer): Prevent relocation of buffer contents during calls to re_search_2. This ensures the pointers into buffer text won't be invalidated by r_alloc_sbrk (called from malloc with configurations where REL_ALLOC=yes). --- src/search.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/src/search.c b/src/search.c index fa5ac44..15504be 100644 --- a/src/search.c +++ b/src/search.c @@ -308,12 +308,20 @@ looking_at_1 (Lisp_Object string, bool posix) re_match_object = Qnil; +#ifdef REL_ALLOC + /* Prevent ralloc.c from relocating the current buffer while + searching it. */ + r_alloc_inhibit_buffer_relocation (1); +#endif i = re_match_2 (bufp, (char *) p1, s1, (char *) p2, s2, PT_BYTE - BEGV_BYTE, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL), ZV_BYTE - BEGV_BYTE); immediate_quit = 0; +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif if (i == -2) matcher_overflow (); @@ -561,8 +569,16 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, buf = compile_pattern (regexp, 0, Qnil, 0, multibyte); immediate_quit = 1; +#ifdef REL_ALLOC + /* Prevent ralloc.c from relocating the current buffer while + searching it. */ + r_alloc_inhibit_buffer_relocation (1); +#endif len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif immediate_quit = 0; return len; @@ -1213,6 +1229,12 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, } re_match_object = Qnil; +#ifdef REL_ALLOC + /* Prevent ralloc.c from relocating the current buffer while + searching it. */ + r_alloc_inhibit_buffer_relocation (1); +#endif + while (n < 0) { ptrdiff_t val; @@ -1254,6 +1276,9 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, else { immediate_quit = 0; +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif return (n); } n++; @@ -1296,11 +1321,17 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, else { immediate_quit = 0; +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif return (0 - n); } n--; } immediate_quit = 0; +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif return (pos); } else /* non-RE case */ -- 2.9.3 [-- Attachment #4: Type: text/plain, Size: 336 bytes --] I did 'make extraclean && . ../config-debug.sh && make' (all in one, to ensure I didn't forget to clean) and it succeeded. > > I'm sorry I didn't look at this closer before, and thus caused you to > work on all those changes, which we might now need to revert. Yes, that's how hindsight works, you only get it when it's too late. ;) ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-25 2:00 ` npostavs @ 2016-10-25 16:03 ` Eli Zaretskii 2016-10-26 0:16 ` npostavs 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-25 16:03 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Mon, 24 Oct 2016 22:00:02 -0400 > > > Maybe we should simply call r_alloc_inhibit_buffer_relocation around > > any calls to regex.c functions, and remove the code you wrote to > > handle relocations internally. > > How's this: Looks OK, please push. > I did 'make extraclean && . ../config-debug.sh && make' (all in one, to > ensure I didn't forget to clean) and it succeeded. That's good, let's hope Michael's problems disappear as well. > > I'm sorry I didn't look at this closer before, and thus caused you to > > work on all those changes, which we might now need to revert. > > Yes, that's how hindsight works, you only get it when it's too late. ;) ;-) Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-25 16:03 ` Eli Zaretskii @ 2016-10-26 0:16 ` npostavs 0 siblings, 0 replies; 76+ messages in thread From: npostavs @ 2016-10-26 0:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sam.halliday, 24358 Eli Zaretskii <eliz@gnu.org> writes: >> From: npostavs@users.sourceforge.net >> Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com >> Date: Mon, 24 Oct 2016 22:00:02 -0400 >> >> > Maybe we should simply call r_alloc_inhibit_buffer_relocation around >> > any calls to regex.c functions, and remove the code you wrote to >> > handle relocations internally. >> >> How's this: > > Looks OK, please push. Pushed as 43986d1, fee4cef. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 13:29 ` npostavs 2016-10-24 13:39 ` Eli Zaretskii @ 2016-10-24 13:43 ` Eli Zaretskii 2016-10-24 14:03 ` Eli Zaretskii 2016-10-24 20:13 ` Sam Halliday 2 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 13:43 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Mon, 24 Oct 2016 09:29:21 -0400 > > The error went away after I updated to the latest emacs-25 commit: > ee04aedc72 "Fix handling of buffer relocation in regex.c functions". > The error occurs in the commit just before it 71ca4f6a "Avoid relocating > buffers while libxml2 reads its text", so I think Eli's fix for the base > pointer in search_buffer does solve the problem. Good to know, thanks. > Sam, can you confirm if this fixes it for you? Fingers crossed. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 13:43 ` Eli Zaretskii @ 2016-10-24 14:03 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 14:03 UTC (permalink / raw) To: npostavs, sam.halliday; +Cc: 24358 > Date: Mon, 24 Oct 2016 16:43:31 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: sam.halliday@gmail.com, 24358@debbugs.gnu.org > > > From: npostavs@users.sourceforge.net > > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > > Date: Mon, 24 Oct 2016 09:29:21 -0400 > > > > The error went away after I updated to the latest emacs-25 commit: > > ee04aedc72 "Fix handling of buffer relocation in regex.c functions". > > The error occurs in the commit just before it 71ca4f6a "Avoid relocating > > buffers while libxml2 reads its text", so I think Eli's fix for the base > > pointer in search_buffer does solve the problem. > > Good to know, thanks. Meanwhile, I fixed yet another potential problem of this class, in replace-match. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 13:29 ` npostavs 2016-10-24 13:39 ` Eli Zaretskii 2016-10-24 13:43 ` Eli Zaretskii @ 2016-10-24 20:13 ` Sam Halliday 2016-10-24 23:44 ` npostavs 2016-11-07 3:39 ` Eli Zaretskii 2 siblings, 2 replies; 76+ messages in thread From: Sam Halliday @ 2016-10-24 20:13 UTC (permalink / raw) To: Noam Postavsky; +Cc: 24358 I built 96ac0c3 and got a problem with the same part of the build, but this time at 10%. Apologies, I don't have the free time to do another debug run on it tonight. I tried with REL_ALLOC=no and that builds fine! Thank you for the workaround. I will still try to help with debug info. Re: docker, it is libre software and you should be able to install it using whatever package manager you have. It allows you to run containerised GNU distributions using your current linux kernel. Pre-built images are made available through the "hocker hub", e.g. https://hub.docker.com/r/base/archlinux/ If you have docker installed you would type something like this (don't forget to add your user to the docker group) docker run -it base/archlinux and (after downloading the "layers"), it will drop you into a shell running that OS. ArchLinux uses "pacman" as the package manager and you might need to run something like "pacman -S devel-base emacs" to get everything you need. Once you exit this shell, all your changes are lost, so you might want to investigate mounting a local directory into the container, e.g. so you don't need to download emacs git tree every time. I'm no expert, I've only used it a few times before but it is invaluable when it works. On 24 October 2016 at 14:29, <npostavs@users.sourceforge.net> wrote: > I was able to reproduce the failure in ja-dic-cnv after removing > --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no > --with-jpeg=no from my configure args (I guess using GTK changes the > allocation patterns), and doing 'make extraclean'. > > The error went away after I updated to the latest emacs-25 commit: > ee04aedc72 "Fix handling of buffer relocation in regex.c functions". > The error occurs in the commit just before it 71ca4f6a "Avoid relocating > buffers while libxml2 reads its text", so I think Eli's fix for the base > pointer in search_buffer does solve the problem. > > Sam, can you confirm if this fixes it for you? > > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: Noam Postavsky <npostavs@users.sourceforge.net> >>> Date: Sun, 23 Oct 2016 14:14:59 -0400 >>> Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org >>> >>> On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii <eliz@gnu.org> wrote: >>> > Noam, I think we need these two changes, because otherwise looping >>> > more than once in search_buffer will fail to update the pointers >>> > passed to re_search_2, if buffer text was relocated inside >>> > re_search_2. >>> > >>> > Do you agree? >>> >>> Ack, yes! Missing the update to base was a total thinko on my part. >> >> Pushed. >> >> There might be a more serious problem with this, unfortunately: the >> search registers are computed in regex.c using pointers into the C >> strings that are being searched. The general paradigm is as in this >> fragment: >> >> regstart[*p] = d; >> [...] >> regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); >> >> POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is >> consistent with the current base address of the string into which it >> points. Did you study this aspect of regex.c when you decided which >> values need to be affected by relocation? > > I did not look at that before, but looking now, I don't see why it would > be a problem. I put the base address updating code around the only > place where malloc may be called, so string1 and string2 (which > POINTER_TO_OFFSET uses) should always be consistent with the base > address (unless there is some other malloc call that I missed?). ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 20:13 ` Sam Halliday @ 2016-10-24 23:44 ` npostavs 2016-11-07 3:39 ` Eli Zaretskii 1 sibling, 0 replies; 76+ messages in thread From: npostavs @ 2016-10-24 23:44 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358 Sam Halliday <sam.halliday@gmail.com> writes: > I built 96ac0c3 and got a problem with the same part of the build, but > this time at 10%. Apologies, I don't have the free time to do another > debug run on it tonight. Ah, I can reproduce this. > > > On 24 October 2016 at 14:29, <npostavs@users.sourceforge.net> wrote: >> I was able to reproduce the failure in ja-dic-cnv after removing >> --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no >> --with-jpeg=no from my configure args (I guess using GTK changes the >> allocation patterns), and doing 'make extraclean'. >> >> The error went away after I updated to the latest emacs-25 commit: >> ee04aedc72 "Fix handling of buffer relocation in regex.c functions". And trying again with ee04aedc72 it fails as well. I must have forgot to clean when running it before. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 20:13 ` Sam Halliday 2016-10-24 23:44 ` npostavs @ 2016-11-07 3:39 ` Eli Zaretskii 2016-11-07 3:56 ` Noam Postavsky 1 sibling, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-11-07 3:39 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Mon, 24 Oct 2016 21:13:33 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, 24358@debbugs.gnu.org > > I built 96ac0c3 and got a problem with the same part of the build, but > this time at 10%. Apologies, I don't have the free time to do another > debug run on it tonight. > > I tried with REL_ALLOC=no and that builds fine! Thank you for the > workaround. I will still try to help with debug info. Is there anything else we should do about this bug? Or can it be closed? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-11-07 3:39 ` Eli Zaretskii @ 2016-11-07 3:56 ` Noam Postavsky 2016-11-07 15:10 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Noam Postavsky @ 2016-11-07 3:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Sam Halliday, 24358 On Sun, Nov 6, 2016 at 10:39 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Sam Halliday <sam.halliday@gmail.com> >> Date: Mon, 24 Oct 2016 21:13:33 +0100 >> Cc: Eli Zaretskii <eliz@gnu.org>, 24358@debbugs.gnu.org >> >> I built 96ac0c3 and got a problem with the same part of the build, but >> this time at 10%. Apologies, I don't have the free time to do another >> debug run on it tonight. >> >> I tried with REL_ALLOC=no and that builds fine! Thank you for the >> workaround. I will still try to help with debug info. > > Is there anything else we should do about this bug? Or can it be > closed? Actually, it was never officially reopened when Sam reported the problems with the first patch. There have been 2 more independent reports that applying this (and the other rel_alloc related fixes) to 25.1 solves the crashing: bug #24821 (which I've merged to this one), and https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00917.html, so I think we're good. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-11-07 3:56 ` Noam Postavsky @ 2016-11-07 15:10 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-11-07 15:10 UTC (permalink / raw) To: Noam Postavsky; +Cc: sam.halliday, 24358 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sun, 6 Nov 2016 22:56:18 -0500 > Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org > > > Is there anything else we should do about this bug? Or can it be > > closed? > > Actually, it was never officially reopened when Sam reported the > problems with the first patch. > > There have been 2 more independent reports that applying this (and the > other rel_alloc related fixes) to 25.1 solves the crashing: bug #24821 > (which I've merged to this one), and > https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00917.html, > so I think we're good. Great, thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 18:06 ` Eli Zaretskii 2016-10-23 18:14 ` Noam Postavsky @ 2016-10-23 18:16 ` Sam Halliday 2016-10-23 19:10 ` Eli Zaretskii 1 sibling, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 18:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs Your patch suggestion results in a failure at 20% in the test for me. I wish we knew what was causing this to fail on my OS but not yours. Do you have docker? You could perhaps try with an recent archlinux image. On 23 October 2016 at 19:06, Eli Zaretskii <eliz@gnu.org> wrote: > Noam, I think we need these two changes, because otherwise looping > more than once in search_buffer will fail to update the pointers > passed to re_search_2, if buffer text was relocated inside > re_search_2. > > Do you agree? > > diff --git a/src/search.c b/src/search.c > index ec5a1d7..5c04916 100644 > --- a/src/search.c > +++ b/src/search.c > @@ -1233,6 +1233,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > ? &search_regs : &search_regs_1), > /* Don't allow match past current point */ > pos_byte - BEGV_BYTE); > + /* Update 'base' due to possible relocation inside re_search_2. */ > + base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); > @@ -1279,6 +1281,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : &search_regs_1), > lim_byte - BEGV_BYTE); > + /* Update 'base' due to possible relocation inside re_search_2. */ > + base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 18:16 ` Sam Halliday @ 2016-10-23 19:10 ` Eli Zaretskii 2016-10-23 19:32 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 19:10 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 19:16:18 +0100 > Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org > > Your patch suggestion results in a failure at 20% in the test for me. So none of the 2 patches work. Which doesn't surprise me: the first was a stab in the dark anyway, and the second is unrelated to the problem you reported. > I wish we knew what was causing this to fail on my OS but not yours. My build doesn't use ralloc.c. It's that simple. > You could perhaps try with an recent archlinux image. What for? The problem is clear from your last Lisp backtrace: a call to string-match returns bad data, which then barfs when used in the following call to substring. The problem is to find the code which causes this. Hmm... ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 19:10 ` Eli Zaretskii @ 2016-10-23 19:32 ` Eli Zaretskii 2016-10-23 20:15 ` Sam Halliday 2016-10-23 20:18 ` Eli Zaretskii 0 siblings, 2 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 19:32 UTC (permalink / raw) To: sam.halliday; +Cc: 24358, npostavs > Date: Sun, 23 Oct 2016 22:10:55 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 24358@debbugs.gnu.org, npostavs@users.sourceforge.net > > The problem is to find the code which causes this. Hmm... Sam, the patch below removes the changes done by Noam in an attempt to solve the original report of this bug. Please apply it, and see if doing so allows you to complete your bootstrap without any errors. Noam, do you configure Emacs with --enable-check-lisp-object-type? If not, please do, because that's what Sam does; perhaps that is the reason why he gets the problem and you don't. One other difference is that Sam is running a bootstrap, so his bootstrap-emacs used to build ja-dic has the necessary Lisp files loaded as *.el files, not *.elc. Therefore another thing to try (perhaps even before reconfiguring) is a full bootstrap, preferably in a separate clean directory, maybe you will see this problem then. Your systems seem to be similar, so I'd expect you both to see the same problems. Here's the patch to remove Noam's changes and Paul's follow-up changes: diff --git a/src/dired.c b/src/dired.c index 006f74c..dba575c 100644 --- a/src/dired.c +++ b/src/dired.c @@ -259,11 +259,9 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, QUIT; bool wanted = (NILP (match) - || (re_match_object = name, - re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0)); + || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting name from GC. */ if (wanted) { diff --git a/src/regex.c b/src/regex.c index b12e95b..164eb46 100644 --- a/src/regex.c +++ b/src/regex.c @@ -152,8 +152,6 @@ /* Converts the pointer to the char to BEG-based offset from the start. */ # define PTR_TO_OFFSET(d) POS_AS_IN_BUFFER (POINTER_TO_OFFSET (d)) -/* Strings are 0-indexed, buffers are 1-indexed; we pun on the boolean - result to get the right base index. */ # define POS_AS_IN_BUFFER(p) ((p) + (NILP (re_match_object) || BUFFERP (re_match_object))) # define RE_MULTIBYTE_P(bufp) ((bufp)->multibyte) @@ -1438,62 +1436,11 @@ typedef struct #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer #define TOP_FAILURE_HANDLE() fail_stack.frame -#ifdef emacs -# define STR_BASE_PTR(obj) \ - (NILP (obj) ? current_buffer->text->beg \ - : STRINGP (obj) ? SDATA (obj) \ - : NULL) -#else -# define STR_BASE_PTR(obj) NULL -#endif #define ENSURE_FAIL_STACK(space) \ while (REMAINING_AVAIL_SLOTS <= space) { \ - re_char *orig_base = STR_BASE_PTR (re_match_object); \ - bool might_relocate = orig_base != NULL; \ - ptrdiff_t string1_off, end1_off, end_match_1_off; \ - ptrdiff_t string2_off, end2_off, end_match_2_off; \ - ptrdiff_t d_off, dend_off, dfail_off; \ - if (might_relocate) \ - { \ - if (string1) \ - { \ - string1_off = string1 - orig_base; \ - end1_off = end1 - orig_base; \ - end_match_1_off = end_match_1 - orig_base; \ - } \ - if (string2) \ - { \ - string2_off = string2 - orig_base; \ - end2_off = end2 - orig_base; \ - end_match_2_off = end_match_2 - orig_base; \ - } \ - d_off = d - orig_base; \ - dend_off = dend - orig_base; \ - dfail_off = dfail - orig_base; \ - } \ if (!GROW_FAIL_STACK (fail_stack)) \ return -2; \ - /* In Emacs, GROW_FAIL_STACK might relocate string pointers. */ \ - if (might_relocate) \ - { \ - re_char *new_base = STR_BASE_PTR (re_match_object); \ - if (string1) \ - { \ - string1 = new_base + string1_off; \ - end1 = new_base + end1_off; \ - end_match_1 = new_base + end_match_1_off; \ - } \ - if (string2) \ - { \ - string2 = new_base + string2_off; \ - end2 = new_base + end2_off; \ - end_match_2 = new_base + end_match_2_off; \ - } \ - d = new_base + d_off; \ - dend = new_base + dend_off; \ - dfail = new_base + dfail_off; \ - } \ DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ } @@ -4380,10 +4327,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, /* Loop through the string, looking for a place to start matching. */ for (;;) { - ptrdiff_t offset1, offset2; - re_char *orig_base; - bool might_relocate; - /* If the pattern is anchored, skip quickly past places we cannot match. We don't bother to treat startpos == 0 specially @@ -4500,17 +4443,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, && !bufp->can_be_null) return -1; - /* re_match_2_internal may allocate, relocating the Lisp text - object that we're searching. */ - IF_LINT (offset2 = 0); /* Work around GCC bug 78081. */ - orig_base = STR_BASE_PTR (re_match_object); - might_relocate = orig_base != NULL; - if (might_relocate) - { - if (string1) offset1 = string1 - orig_base; - if (string2) offset2 = string2 - orig_base; - } - val = re_match_2_internal (bufp, string1, size1, string2, size2, startpos, regs, stop); @@ -4520,13 +4452,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, if (val == -2) return -2; - if (might_relocate) - { - re_char *new_base = STR_BASE_PTR (re_match_object); - if (string1) string1 = offset1 + new_base; - if (string2) string2 = offset2 + new_base; - } - advance: if (!range) break; @@ -4962,8 +4887,8 @@ WEAK_ALIAS (__re_match, re_match) #endif /* not emacs */ #ifdef emacs -/* In Emacs, this is the string or buffer in which we are matching. - See the declaration in regex.h for details. */ +/* In Emacs, this is the string or buffer in which we + are matching. It is used for looking up syntax properties. */ Lisp_Object re_match_object; #endif diff --git a/src/search.c b/src/search.c index 5c04916..dc7e2d8 100644 --- a/src/search.c +++ b/src/search.c @@ -287,10 +287,8 @@ looking_at_1 (Lisp_Object string, bool posix) immediate_quit = 1; QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get pointers and sizes of the two strings that make up the - visible portion of the buffer. Note that we can use pointers - here, unlike in search_buffer, because we only call re_match_2 - once, after which we never use the pointers again. */ + /* Get pointers and sizes of the two strings + that make up the visible portion of the buffer. */ p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; @@ -409,7 +407,6 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, (NILP (Vinhibit_changing_match_data) ? &search_regs : NULL)); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ /* Set last_thing_searched only when match data is changed. */ if (NILP (Vinhibit_changing_match_data)) @@ -480,7 +477,6 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, SBYTES (string), 0, SBYTES (string), 0); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ return val; } @@ -568,7 +564,6 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, pos_byte, NULL, limit_byte); immediate_quit = 0; - re_match_object = Qnil; /* Stop protecting string from GC. */ return len; } @@ -1183,8 +1178,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) { - unsigned char *base; - ptrdiff_t off1, off2, s1, s2; + unsigned char *p1, *p2; + ptrdiff_t s1, s2; struct re_pattern_buffer *bufp; bufp = compile_pattern (string, @@ -1198,19 +1193,16 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, can take too long. */ QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ - /* Get offsets and sizes of the two strings that make up the - visible portion of the buffer. We compute offsets instead of - pointers because re_search_2 may call malloc and therefore - change the buffer text address. */ + /* Get pointers and sizes of the two strings + that make up the visible portion of the buffer. */ - base = current_buffer->text->beg; - off1 = BEGV_ADDR - base; + p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; - off2 = GAP_END_ADDR - base; + p2 = GAP_END_ADDR; s2 = ZV_BYTE - GPT_BYTE; if (s1 < 0) { - off2 = off1; + p2 = p1; s2 = ZV_BYTE - BEGV_BYTE; s1 = 0; } @@ -1225,16 +1217,12 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, - (char*) (base + off1), s1, - (char*) (base + off2), s2, + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), /* Don't allow match past current point */ pos_byte - BEGV_BYTE); - /* Update 'base' due to possible relocation inside re_search_2. */ - base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); @@ -1274,15 +1262,11 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, { ptrdiff_t val; - val = re_search_2 (bufp, - (char*) (base + off1), s1, - (char*) (base + off2), s2, - pos_byte - BEGV_BYTE, lim_byte - pos_byte, + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, + pos_byte - BEGV_BYTE, lim_byte - pos_byte, (NILP (Vinhibit_changing_match_data) ? &search_regs : &search_regs_1), lim_byte - BEGV_BYTE); - /* Update 'base' due to possible relocation inside re_search_2. */ - base = current_buffer->text->beg; if (val == -2) { matcher_overflow (); ^ permalink raw reply related [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 19:32 ` Eli Zaretskii @ 2016-10-23 20:15 ` Sam Halliday 2016-10-23 20:27 ` Eli Zaretskii 2016-10-23 20:18 ` Eli Zaretskii 1 sibling, 1 reply; 76+ messages in thread From: Sam Halliday @ 2016-10-23 20:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, Noam Postavsky Sorry Eli, this patch doesn't apply cleanly for me. I'm on the tip of emacs-25 and I get failures in dired.c, regex.c and search.c that aren't easy for me to resolve. I'm happy to keep being guinea pig so you can fix this, but as a workaround so that I can have a more stable Emacs to get my main work done, is there a way for me to force the use of a less jumpy malloc implementation? It sounds like whatever happened in ArchLinux has meant that Emacs now prefers ralloc whereas previously it may not. On 23 October 2016 at 20:32, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sun, 23 Oct 2016 22:10:55 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 24358@debbugs.gnu.org, npostavs@users.sourceforge.net >> >> The problem is to find the code which causes this. Hmm... > > Sam, the patch below removes the changes done by Noam in an attempt to > solve the original report of this bug. Please apply it, and see if > doing so allows you to complete your bootstrap without any errors. > > Noam, do you configure Emacs with --enable-check-lisp-object-type? > If not, please do, because that's what Sam does; perhaps that is the > reason why he gets the problem and you don't. > > One other difference is that Sam is running a bootstrap, so his > bootstrap-emacs used to build ja-dic has the necessary Lisp files > loaded as *.el files, not *.elc. Therefore another thing to try > (perhaps even before reconfiguring) is a full bootstrap, preferably in > a separate clean directory, maybe you will see this problem then. > > Your systems seem to be similar, so I'd expect you both to see the > same problems. > > Here's the patch to remove Noam's changes and Paul's follow-up > changes: > > diff --git a/src/dired.c b/src/dired.c > index 006f74c..dba575c 100644 > --- a/src/dired.c > +++ b/src/dired.c > @@ -259,11 +259,9 @@ directory_files_internal (Lisp_Object directory, Lisp_Object full, > QUIT; > > bool wanted = (NILP (match) > - || (re_match_object = name, > - re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0)); > + || re_search (bufp, SSDATA (name), len, 0, len, 0) >= 0); > > immediate_quit = 0; > - re_match_object = Qnil; /* Stop protecting name from GC. */ > > if (wanted) > { > diff --git a/src/regex.c b/src/regex.c > index b12e95b..164eb46 100644 > --- a/src/regex.c > +++ b/src/regex.c > @@ -152,8 +152,6 @@ > > /* Converts the pointer to the char to BEG-based offset from the start. */ > # define PTR_TO_OFFSET(d) POS_AS_IN_BUFFER (POINTER_TO_OFFSET (d)) > -/* Strings are 0-indexed, buffers are 1-indexed; we pun on the boolean > - result to get the right base index. */ > # define POS_AS_IN_BUFFER(p) ((p) + (NILP (re_match_object) || BUFFERP (re_match_object))) > > # define RE_MULTIBYTE_P(bufp) ((bufp)->multibyte) > @@ -1438,62 +1436,11 @@ typedef struct > #define NEXT_FAILURE_HANDLE(h) fail_stack.stack[(h) - 3].integer > #define TOP_FAILURE_HANDLE() fail_stack.frame > > -#ifdef emacs > -# define STR_BASE_PTR(obj) \ > - (NILP (obj) ? current_buffer->text->beg \ > - : STRINGP (obj) ? SDATA (obj) \ > - : NULL) > -#else > -# define STR_BASE_PTR(obj) NULL > -#endif > > #define ENSURE_FAIL_STACK(space) \ > while (REMAINING_AVAIL_SLOTS <= space) { \ > - re_char *orig_base = STR_BASE_PTR (re_match_object); \ > - bool might_relocate = orig_base != NULL; \ > - ptrdiff_t string1_off, end1_off, end_match_1_off; \ > - ptrdiff_t string2_off, end2_off, end_match_2_off; \ > - ptrdiff_t d_off, dend_off, dfail_off; \ > - if (might_relocate) \ > - { \ > - if (string1) \ > - { \ > - string1_off = string1 - orig_base; \ > - end1_off = end1 - orig_base; \ > - end_match_1_off = end_match_1 - orig_base; \ > - } \ > - if (string2) \ > - { \ > - string2_off = string2 - orig_base; \ > - end2_off = end2 - orig_base; \ > - end_match_2_off = end_match_2 - orig_base; \ > - } \ > - d_off = d - orig_base; \ > - dend_off = dend - orig_base; \ > - dfail_off = dfail - orig_base; \ > - } \ > if (!GROW_FAIL_STACK (fail_stack)) \ > return -2; \ > - /* In Emacs, GROW_FAIL_STACK might relocate string pointers. */ \ > - if (might_relocate) \ > - { \ > - re_char *new_base = STR_BASE_PTR (re_match_object); \ > - if (string1) \ > - { \ > - string1 = new_base + string1_off; \ > - end1 = new_base + end1_off; \ > - end_match_1 = new_base + end_match_1_off; \ > - } \ > - if (string2) \ > - { \ > - string2 = new_base + string2_off; \ > - end2 = new_base + end2_off; \ > - end_match_2 = new_base + end_match_2_off; \ > - } \ > - d = new_base + d_off; \ > - dend = new_base + dend_off; \ > - dfail = new_base + dfail_off; \ > - } \ > DEBUG_PRINT ("\n Doubled stack; size now: %zd\n", (fail_stack).size);\ > DEBUG_PRINT (" slots available: %zd\n", REMAINING_AVAIL_SLOTS);\ > } > @@ -4380,10 +4327,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, > /* Loop through the string, looking for a place to start matching. */ > for (;;) > { > - ptrdiff_t offset1, offset2; > - re_char *orig_base; > - bool might_relocate; > - > /* If the pattern is anchored, > skip quickly past places we cannot match. > We don't bother to treat startpos == 0 specially > @@ -4500,17 +4443,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, > && !bufp->can_be_null) > return -1; > > - /* re_match_2_internal may allocate, relocating the Lisp text > - object that we're searching. */ > - IF_LINT (offset2 = 0); /* Work around GCC bug 78081. */ > - orig_base = STR_BASE_PTR (re_match_object); > - might_relocate = orig_base != NULL; > - if (might_relocate) > - { > - if (string1) offset1 = string1 - orig_base; > - if (string2) offset2 = string2 - orig_base; > - } > - > val = re_match_2_internal (bufp, string1, size1, string2, size2, > startpos, regs, stop); > > @@ -4520,13 +4452,6 @@ re_search_2 (struct re_pattern_buffer *bufp, const char *str1, size_t size1, > if (val == -2) > return -2; > > - if (might_relocate) > - { > - re_char *new_base = STR_BASE_PTR (re_match_object); > - if (string1) string1 = offset1 + new_base; > - if (string2) string2 = offset2 + new_base; > - } > - > advance: > if (!range) > break; > @@ -4962,8 +4887,8 @@ WEAK_ALIAS (__re_match, re_match) > #endif /* not emacs */ > > #ifdef emacs > -/* In Emacs, this is the string or buffer in which we are matching. > - See the declaration in regex.h for details. */ > +/* In Emacs, this is the string or buffer in which we > + are matching. It is used for looking up syntax properties. */ > Lisp_Object re_match_object; > #endif > > diff --git a/src/search.c b/src/search.c > index 5c04916..dc7e2d8 100644 > --- a/src/search.c > +++ b/src/search.c > @@ -287,10 +287,8 @@ looking_at_1 (Lisp_Object string, bool posix) > immediate_quit = 1; > QUIT; /* Do a pending quit right away, to avoid paradoxical behavior */ > > - /* Get pointers and sizes of the two strings that make up the > - visible portion of the buffer. Note that we can use pointers > - here, unlike in search_buffer, because we only call re_match_2 > - once, after which we never use the pointers again. */ > + /* Get pointers and sizes of the two strings > + that make up the visible portion of the buffer. */ > > p1 = BEGV_ADDR; > s1 = GPT_BYTE - BEGV_BYTE; > @@ -409,7 +407,6 @@ string_match_1 (Lisp_Object regexp, Lisp_Object string, Lisp_Object start, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : NULL)); > immediate_quit = 0; > - re_match_object = Qnil; /* Stop protecting string from GC. */ > > /* Set last_thing_searched only when match data is changed. */ > if (NILP (Vinhibit_changing_match_data)) > @@ -480,7 +477,6 @@ fast_string_match_internal (Lisp_Object regexp, Lisp_Object string, > SBYTES (string), 0, > SBYTES (string), 0); > immediate_quit = 0; > - re_match_object = Qnil; /* Stop protecting string from GC. */ > return val; > } > > @@ -568,7 +564,6 @@ fast_looking_at (Lisp_Object regexp, ptrdiff_t pos, ptrdiff_t pos_byte, > len = re_match_2 (buf, (char *) p1, s1, (char *) p2, s2, > pos_byte, NULL, limit_byte); > immediate_quit = 0; > - re_match_object = Qnil; /* Stop protecting string from GC. */ > > return len; > } > @@ -1183,8 +1178,8 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > > if (RE && !(trivial_regexp_p (string) && NILP (Vsearch_spaces_regexp))) > { > - unsigned char *base; > - ptrdiff_t off1, off2, s1, s2; > + unsigned char *p1, *p2; > + ptrdiff_t s1, s2; > struct re_pattern_buffer *bufp; > > bufp = compile_pattern (string, > @@ -1198,19 +1193,16 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > can take too long. */ > QUIT; /* Do a pending quit right away, > to avoid paradoxical behavior */ > - /* Get offsets and sizes of the two strings that make up the > - visible portion of the buffer. We compute offsets instead of > - pointers because re_search_2 may call malloc and therefore > - change the buffer text address. */ > + /* Get pointers and sizes of the two strings > + that make up the visible portion of the buffer. */ > > - base = current_buffer->text->beg; > - off1 = BEGV_ADDR - base; > + p1 = BEGV_ADDR; > s1 = GPT_BYTE - BEGV_BYTE; > - off2 = GAP_END_ADDR - base; > + p2 = GAP_END_ADDR; > s2 = ZV_BYTE - GPT_BYTE; > if (s1 < 0) > { > - off2 = off1; > + p2 = p1; > s2 = ZV_BYTE - BEGV_BYTE; > s1 = 0; > } > @@ -1225,16 +1217,12 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > { > ptrdiff_t val; > > - val = re_search_2 (bufp, > - (char*) (base + off1), s1, > - (char*) (base + off2), s2, > + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, > pos_byte - BEGV_BYTE, lim_byte - pos_byte, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : &search_regs_1), > /* Don't allow match past current point */ > pos_byte - BEGV_BYTE); > - /* Update 'base' due to possible relocation inside re_search_2. */ > - base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); > @@ -1274,15 +1262,11 @@ search_buffer (Lisp_Object string, ptrdiff_t pos, ptrdiff_t pos_byte, > { > ptrdiff_t val; > > - val = re_search_2 (bufp, > - (char*) (base + off1), s1, > - (char*) (base + off2), s2, > - pos_byte - BEGV_BYTE, lim_byte - pos_byte, > + val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, > + pos_byte - BEGV_BYTE, lim_byte - pos_byte, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : &search_regs_1), > lim_byte - BEGV_BYTE); > - /* Update 'base' due to possible relocation inside re_search_2. */ > - base = current_buffer->text->beg; > if (val == -2) > { > matcher_overflow (); ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 20:15 ` Sam Halliday @ 2016-10-23 20:27 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 20:27 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358, npostavs > From: Sam Halliday <sam.halliday@gmail.com> > Date: Sun, 23 Oct 2016 21:15:11 +0100 > Cc: 24358@debbugs.gnu.org, Noam Postavsky <npostavs@users.sourceforge.net> > > Sorry Eli, this patch doesn't apply cleanly for me. I'm on the tip of > emacs-25 and I get failures in dired.c, regex.c and search.c that > aren't easy for me to resolve. Strange, I prepared this with "git diff" on emacs-25 branch. OK, can you reset dired.c, regex.c and search.c to their state as of commit 5a26c9b0e1b0d9a2de35e0a8b0a803017e70def0 instead? This is one commit before Noam made his changes. > I'm happy to keep being guinea pig so you can fix this, but as a > workaround so that I can have a more stable Emacs to get my main work > done, is there a way for me to force the use of a less jumpy malloc > implementation? Apart from downgrading to an older glibc version, I'm not aware of any way. > It sounds like whatever happened in ArchLinux has meant that Emacs > now prefers ralloc whereas previously it may not. Yes, I think so. But we cannot ask users to not upgrade to newer glibc, so we must solve these problems somehow. If you can afford being a guinea pig for a little bit longer, I'd appreciate that, as otherwise I don't know how to proceed with this bug. Other people are also seeing similar problems, e.g., see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24772#11 Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 19:32 ` Eli Zaretskii 2016-10-23 20:15 ` Sam Halliday @ 2016-10-23 20:18 ` Eli Zaretskii 2016-10-23 23:18 ` Noam Postavsky 1 sibling, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-23 20:18 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 Noam, there's something I don't understand here: why is regex.c using malloc for allocating the failure stack? AFAICS, REGEX_MALLOC is not defined, so the only way I can explain this to myself is that we use SAFE_ALLOCA, and that falls back to malloc because the failure stack needs more than 16KB of memory. Is that correct? If so, then one other way of solving the original problem that doesn't open the gates of the ralloc.c hell is to allow a larger amount of stack allocations in regex.c before we fall back to malloc. Since the maximum size of the failure stack is limited by something like 800KB, and the C stack limit is set in main.c to allow the failure stack be allocated off the stack, why don't we make use of this fact? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 20:18 ` Eli Zaretskii @ 2016-10-23 23:18 ` Noam Postavsky 2016-10-24 7:05 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Noam Postavsky @ 2016-10-23 23:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Sam Halliday, 24358 Eli Zaretskii <eliz@gnu.org> wrote: > Noam, do you configure Emacs with --enable-check-lisp-object-type? > If not, please do, because that's what Sam does; perhaps that is the > reason why he gets the problem and you don't. > > One other difference is that Sam is running a bootstrap, so his > bootstrap-emacs used to build ja-dic has the necessary Lisp files > loaded as *.el files, not *.elc. Therefore another thing to try > (perhaps even before reconfiguring) is a full bootstrap, preferably in > a separate clean directory, maybe you will see this problem then. I will try both of these tomorrow. Sam, if you want to post the docker thing somewhere I can give that a try tomorrow as well, in case Eli's suggestions are not sufficient to reproduce this. > Noam, there's something I don't understand here: why is regex.c using > malloc for allocating the failure stack? AFAICS, REGEX_MALLOC is not > defined, so the only way I can explain this to myself is that we use > SAFE_ALLOCA, and that falls back to malloc because the failure stack > needs more than 16KB of memory. Is that correct? Yes, this is correct, see also http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#47 > > If so, then one other way of solving the original problem that doesn't > open the gates of the ralloc.c hell is to allow a larger amount of > stack allocations in regex.c before we fall back to malloc. Since the > maximum size of the failure stack is limited by something like 800KB, > and the C stack limit is set in main.c to allow the failure stack be > allocated off the stack, why don't we make use of this fact? It sounds reasonable in principle. This would mean changing MAX_ALLOCA? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 23:18 ` Noam Postavsky @ 2016-10-24 7:05 ` Eli Zaretskii 2016-10-24 8:40 ` Eli Zaretskii 0 siblings, 1 reply; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 7:05 UTC (permalink / raw) To: Noam Postavsky; +Cc: sam.halliday, 24358 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sun, 23 Oct 2016 19:18:32 -0400 > Cc: Sam Halliday <sam.halliday@gmail.com>, 24358@debbugs.gnu.org > > Eli Zaretskii <eliz@gnu.org> wrote: > > Noam, do you configure Emacs with --enable-check-lisp-object-type? > > If not, please do, because that's what Sam does; perhaps that is the > > reason why he gets the problem and you don't. > > > > One other difference is that Sam is running a bootstrap, so his > > bootstrap-emacs used to build ja-dic has the necessary Lisp files > > loaded as *.el files, not *.elc. Therefore another thing to try > > (perhaps even before reconfiguring) is a full bootstrap, preferably in > > a separate clean directory, maybe you will see this problem then. > > I will try both of these tomorrow. Thanks. Here are some other things to try, if you (or someone else) have time: . build regex.c with REGEX_MALLOC defined, and see whether your recent additions to cater to relocation are needed with that configuration . build with gmalloc.c, but without ralloc.c (I will try to come up with a recipe or a patch for that later today, if no one beats me to it) . surround the calls to regex.c functions in search.c and elsewhere with the calls to r_alloc_inhibit_buffer_relocation, again without your recent additions to regex.c (the problem with this is that it must be tested in long, real-life sessions, because in the past using that workaround caused very rare crashes in ralloc.c itself, which were supposed to be fixed, but were never tested thoroughly enough, AFAIK) > > Noam, there's something I don't understand here: why is regex.c using > > malloc for allocating the failure stack? AFAICS, REGEX_MALLOC is not > > defined, so the only way I can explain this to myself is that we use > > SAFE_ALLOCA, and that falls back to malloc because the failure stack > > needs more than 16KB of memory. Is that correct? > > Yes, this is correct, see also > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#47 > > > > > If so, then one other way of solving the original problem that doesn't > > open the gates of the ralloc.c hell is to allow a larger amount of > > stack allocations in regex.c before we fall back to malloc. Since the > > maximum size of the failure stack is limited by something like 800KB, > > and the C stack limit is set in main.c to allow the failure stack be > > allocated off the stack, why don't we make use of this fact? > > It sounds reasonable in principle. This would mean changing MAX_ALLOCA? Actually, it probably means using a different definition for SAFE_ALLOCA in regex.c, or a separate macro. I don't see the need to increase stack usage elsewhere in Emacs. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-24 7:05 ` Eli Zaretskii @ 2016-10-24 8:40 ` Eli Zaretskii 0 siblings, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-24 8:40 UTC (permalink / raw) To: npostavs; +Cc: sam.halliday, 24358 > Date: Mon, 24 Oct 2016 10:05:58 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: sam.halliday@gmail.com, 24358@debbugs.gnu.org > > . build with gmalloc.c, but without ralloc.c (I will try to come up > with a recipe or a patch for that later today, if no one beats me > to it) This should work, I think: $ REL_ALLOC=no CFLAGS='<whatever>' ... ./configure ... IOW, set REL_ALLOC=no before running the configure script, and leave the rest of the settings and configure switches intact. If this works, you should see Should Emacs use a relocating allocator for buffers? no at the end of the configure run, and src/config.h should have /* Define REL_ALLOC if you want to use the relocating allocator for buffer space. */ /* #undef REL_ALLOC */ gmalloc.c should still be compiled, but ralloc.c should not (delete ralloc.o to be sure). Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" 2016-10-23 17:19 ` Eli Zaretskii 2016-10-23 18:06 ` Eli Zaretskii @ 2016-10-23 18:11 ` Sam Halliday 1 sibling, 0 replies; 76+ messages in thread From: Sam Halliday @ 2016-10-23 18:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24358, npostavs The failure occurs at 20% if I delete the line (which seems to have moved to line 412). Some more debugging, human readable first two frames: (gdb) f 1 #1 0x00000000006351d9 in xsignal (error_symbol=..., data=...) at eval.c:1582 1582 Fsignal (error_symbol, data); (gdb) p error_symbol $8 = { i = 9600 } (gdb) xpr Lisp_Symbol $9 = (struct Lisp_Symbol *) 0xdb0610 <lispsym+9600> "args-out-of-range" (gdb) p data $10 = { i = 116316307 } (gdb) xpr Lisp_Cons $11 = (struct Lisp_Cons *) 0x6eed890 { car = { i = 0x3cff3c4 }, u = { cdr = { i = 0x6eed8a3 }, chain = 0x6eed8a3 } } (gdb) f 2 #2 0x00000000006352ae in xsignal3 (error_symbol=..., arg1=..., arg2=..., arg3=...) at eval.c:1609 1609 xsignal (error_symbol, list3 (arg1, arg2, arg3)); (gdb) p error_symbol $12 = { i = 9600 } (gdb) xpr Lisp_Symbol $13 = (struct Lisp_Symbol *) 0xdb0610 <lispsym+9600> "args-out-of-range" (gdb) p arg1 $14 = { i = 63960004 } (gdb) xpr Lisp_String $15 = (struct Lisp_String *) 0x3cff3c0 "七宝焼/" (gdb) p arg2 $16 = { i = -18 } (gdb) xpr Lisp_Int1 $17 = -5 (gdb) p arg3 $18 = { i = 0 } (gdb) xpr Lisp_Symbol $19 = (struct Lisp_Symbol *) 0xdae090 <lispsym> "nil" On 23 October 2016 at 18:19, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Sam Halliday <sam.halliday@gmail.com> >> Date: Sun, 23 Oct 2016 16:58:07 +0100 >> Cc: npostavs@users.sourceforge.net, 24358@debbugs.gnu.org >> >> Processing OKURI-NASI entries ... >> processed 10% ... >> processed 20% ... >> processed 30% ... >> processed 40% ... >> >> Thread 1 "emacs" hit Breakpoint 2, Fsignal (error_symbol=..., >> data=...) at eval.c:1476 >> 1476 = (NILP (error_symbol) ? Fcar (data) : error_symbol); >> (gdb) xbacktrace >> "substring" (0xffff6f00) >> "string=" (0xffff70a0) >> "if" (0xffff7230) >> "while" (0xffff7400) >> "catch" (0xffff7600) >> "let" (0xffff7860) >> "and" (0xffff79f0) >> "let" (0xffff7c50) >> "and" (0xffff7de0) >> "or" (0xffff7f70) >> "let" (0xffff81d0) >> "skkdic-breakup-string" (0xffff8380) > > Thanks. > > Does it help to delete this line: > > re_match_object = Qnil; /* Stop protecting string from GC. */ > > in src/search.c:string_match_1 (should be line 404)? ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; 2016-08-26 20:17 bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Peder O. Klingenberg 2016-08-27 3:35 ` npostavs @ 2016-10-18 8:16 ` Sam Halliday 2016-10-18 8:56 ` Sam Halliday 2016-10-18 9:28 ` Eli Zaretskii 1 sibling, 2 replies; 76+ messages in thread From: Sam Halliday @ 2016-10-18 8:16 UTC (permalink / raw) To: 24358 I've also been experiencing this bug and I raised a thread about it on the ArchLinux forums: https://bbs.archlinux.org/viewtopic.php?pid=1662221 I have built the emacs-25 branch with debugging flags "-O0 -gdwarf-4 -g3" as advised. I can (unreliably) reproduce by typing `M-x ensime` and it seems like emacs is crashing when loading the .ensime file, which is an s-expression file that is loaded as data in https://github.com/ensime/ensime-emacs/blob/master/ensime-config.el#L153-L168 (actually if anybody knows of a more efficient way to load the file, I'd be keen to update our code, I'm a maintainer). The exact file that it is apparently performing the re_search within is https://gist.github.com/fommil/d906918819cd2632e9864842e1d59b57 I get this on segfault ===== Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. 0x00000000005bdd06 in re_search_2 (bufp=0xc49b30 <searchbufs+3632>, str1=0x56e5508 <error: Cannot access memory at address 0x56e5508>, size1=0, str2=0x56e5508 <error: Cannot access memory at address 0x56e5508>, size2=65565, startpos=646, range=509, regs=0xc4a930 <search_regs>, stop=1155) at regex.c:4464 4464 int len = BYTES_BY_CHAR_HEAD (*p); ===== and a bt on the core follows (sorry, huge dump). Could somebody please let me know how to dig into 0x56e5508 (if relevant)? I have never used gdb in anger. #0 0x00000000005bdd06 in re_search_2 (bufp=0xc49b30 <searchbufs+3632>, str1=0x56e5508 <error: Cannot access memory at address 0x56e5508>, size1=0, str2=0x56e5508 <error: Cannot access memory at address 0x56e5508>, size2=65565, startpos=646, range=509, regs=0xc4a930 <search_regs>, stop=1155) at regex.c:4464 #1 0x00000000005acc42 in search_buffer (string=14269316, pos=624, pos_byte=624, lim=1156, lim_byte=1156, n=1, RE=1, trt=0, inverse_trt=0, posix=false) at search.c:1265 #2 0x00000000005ac4b8 in search_command (string=14269316, bound=4626, noerror=44544, count=0, direction=1, RE=1, posix=false) at search.c:1058 #3 0x00000000005b00df in Fre_search_forward (regexp=14269316, bound=4626, noerror=44544, count=0) at search.c:2264 #4 0x00000000005eec29 in Ffuncall (nargs=4, args=0x7ffffffefad8) at eval.c:2709 #5 0x0000000000630d52 in exec_byte_code (bytestr=10818516, vector=10818549, maxdepth=38, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #6 0x00000000005ef6f1 in funcall_lambda (fun=10818469, nargs=3, arg_vector=0xa513f5 <pure+1329237>) at eval.c:2928 #7 0x00000000005eedfa in Ffuncall (nargs=4, args=0x7fffffff0028) at eval.c:2747 #8 0x0000000000630d52 in exec_byte_code (bytestr=10813244, vector=10813277, maxdepth=22, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #9 0x00000000005ef6f1 in funcall_lambda (fun=10813165, nargs=3, arg_vector=0xa4ff5d <pure+1323965>) at eval.c:2928 #10 0x00000000005eedfa in Ffuncall (nargs=4, args=0x7fffffff0558) at eval.c:2747 #11 0x0000000000630d52 in exec_byte_code (bytestr=10810988, vector=10811021, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #12 0x00000000005ef6f1 in funcall_lambda (fun=10810877, nargs=2, arg_vector=0xa4f68d <pure+1321709>) at eval.c:2928 #13 0x00000000005eedfa in Ffuncall (nargs=3, args=0x7fffffff0a90) at eval.c:2747 #14 0x0000000000630d52 in exec_byte_code (bytestr=10832908, vector=50228949, maxdepth=42, args_template=1030, nargs=1, args=0x7fffffff1190) at bytecode.c:880 #15 0x00000000005ef3b5 in funcall_lambda (fun=50229021, nargs=1, arg_vector=0x7fffffff1188) at eval.c:2862 #16 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffff1180) at eval.c:2747 #17 0x00000000005ee202 in run_hook_wrapped_funcall (nargs=2, args=0x7fffffff1180) at eval.c:2433 #18 0x00000000005ee459 in run_hook_with_args (nargs=2, args=0x7fffffff1180, funcall=0x5ee1b6 <run_hook_wrapped_funcall>) at eval.c:2514 #19 0x00000000005ee251 in Frun_hook_wrapped (nargs=2, args=0x7fffffff1180) at eval.c:2448 #20 0x00000000005eea79 in Ffuncall (nargs=3, args=0x7fffffff1178) at eval.c:2678 #21 0x0000000000630d52 in exec_byte_code (bytestr=10832780, vector=10832813, maxdepth=78, args_template=2058, nargs=2, args=0x7fffffff1730) at bytecode.c:880 #22 0x00000000005ef3b5 in funcall_lambda (fun=10832733, nargs=2, arg_vector=0x7fffffff1720) at eval.c:2862 #23 0x00000000005eedfa in Ffuncall (nargs=3, args=0x7fffffff1718) at eval.c:2747 #24 0x0000000000630d52 in exec_byte_code (bytestr=10833076, vector=10833109, maxdepth=110, args_template=2050, nargs=2, args=0x7fffffff1ce8) at bytecode.c:880 #25 0x00000000005ef3b5 in funcall_lambda (fun=10833029, nargs=2, arg_vector=0x7fffffff1cd8) at eval.c:2862 #26 0x00000000005eedfa in Ffuncall (nargs=3, args=0x7fffffff1cd0) at eval.c:2747 #27 0x0000000000630d52 in exec_byte_code (bytestr=10832452, vector=10832485, maxdepth=50, args_template=1030, nargs=1, args=0x7fffffff22a0) at bytecode.c:880 #28 0x00000000005ef3b5 in funcall_lambda (fun=10832405, nargs=1, arg_vector=0x7fffffff2298) at eval.c:2862 #29 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffff2290) at eval.c:2747 #30 0x00000000005ebc6f in internal_condition_case_n (bfun=0x5ee7f9 <Ffuncall>, nargs=2, args=0x7fffffff2290, handlers=44544, hfun= 0x43cbff <safe_eval_handler>) at eval.c:1394 #31 0x000000000043ce50 in safe__call (inhibit_quit=false, nargs=2, func=9481216, ap=0x7fffffff2350) at xdisp.c:2558 #32 0x000000000043cf43 in safe_call (nargs=2, func=9481216) at xdisp.c:2574 #33 0x000000000043cf7d in safe_call1 (fn=9481216, arg=2498) at xdisp.c:2585 #34 0x000000000043fecc in handle_fontified_prop (it=0x7fffffff3af0) at xdisp.c:3805 #35 0x000000000043eec7 in handle_stop (it=0x7fffffff3af0) at xdisp.c:3371 #36 0x000000000044bd29 in next_element_from_buffer (it=0x7fffffff3af0) at xdisp.c:8322 #37 0x0000000000448302 in get_next_display_element (it=0x7fffffff3af0) at xdisp.c:6922 #38 0x000000000046ec93 in display_line (it=0x7fffffff3af0) at xdisp.c:20598 #39 0x000000000046450e in try_window (window=20368437, pos=..., flags=1) at xdisp.c:17247 #40 0x0000000000461937 in redisplay_window (window=20368437, just_this_one_p=false) at xdisp.c:16696 #41 0x000000000045a803 in redisplay_window_0 (window=20368437) at xdisp.c:14487 #42 0x00000000005ebb1d in internal_condition_case_1 (bfun=0x45a7c1 <redisplay_window_0>, arg=20368437, handlers=13659203, hfun=0x45a789 <redisplay_window_error>) at eval.c:1338 #43 0x000000000045a766 in redisplay_windows (window=20368437) at xdisp.c:14467 #44 0x0000000000459893 in redisplay_internal () at xdisp.c:14027 #45 0x000000000045a183 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:14320 #46 0x0000000000635b28 in Fdelete_process (process=50226429) at process.c:873 #47 0x00000000005eeb78 in Ffuncall (nargs=2, args=0x7fffffff8b48) at eval.c:2698 #48 0x0000000000630d52 in exec_byte_code (bytestr=16680580, vector=19382253, maxdepth=18, args_template=2058, nargs=2, args=0x7fffffff90a0) at bytecode.c:880 #49 0x00000000005ef3b5 in funcall_lambda (fun=48360773, nargs=2, arg_vector=0x7fffffff9090) at eval.c:2862 #50 0x00000000005eedfa in Ffuncall (nargs=3, args=0x7fffffff9088) at eval.c:2747 #51 0x0000000000630d52 in exec_byte_code (bytestr=54486340, vector=47296317, maxdepth=30, args_template=1030, nargs=1, args=0x7fffffff95b8) at bytecode.c:880 #52 0x00000000005ef3b5 in funcall_lambda (fun=47296397, nargs=1, arg_vector=0x7fffffff95b0) at eval.c:2862 #53 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffff95a8) at eval.c:2747 #54 0x0000000000630d52 in exec_byte_code (bytestr=54504036, vector=47287597, maxdepth=10, args_template=2, nargs=0, args=0x7fffffff9ad0) at bytecode.c:880 #55 0x00000000005ef3b5 in funcall_lambda (fun=47287653, nargs=0, arg_vector=0x7fffffff9ad0) at eval.c:2862 #56 0x00000000005eedfa in Ffuncall (nargs=1, args=0x7fffffff9ac8) at eval.c:2747 #57 0x0000000000630d52 in exec_byte_code (bytestr=54527172, vector=47283725, maxdepth=6, args_template=2, nargs=0, args=0x7fffffffa080) at bytecode.c:880 #58 0x00000000005ef3b5 in funcall_lambda (fun=47283773, nargs=0, arg_vector=0x7fffffffa080) at eval.c:2862 #59 0x00000000005eedfa in Ffuncall (nargs=1, args=0x7fffffffa078) at eval.c:2747 #60 0x00000000005ee058 in funcall_nil (nargs=1, args=0x7fffffffa078) at eval.c:2337 #61 0x00000000005ee459 in run_hook_with_args (nargs=1, args=0x7fffffffa078, funcall=0x5ee035 <funcall_nil>) at eval.c:2514 #62 0x00000000005ee0df in Frun_hook_with_args (nargs=1, args=0x7fffffffa078) at eval.c:2379 #63 0x00000000005ee4b8 in run_hook (hook=41424256) at eval.c:2527 #64 0x000000000057a033 in Fkill_buffer (buffer_or_name=37882885) at buffer.c:1680 #65 0x00000000005eeb78 in Ffuncall (nargs=2, args=0x7fffffffa228) at eval.c:2698 #66 0x0000000000630d52 in exec_byte_code (bytestr=52539684, vector=29921029, maxdepth=22, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #67 0x00000000005ef6f1 in funcall_lambda (fun=29921173, nargs=1, arg_vector=0x1c88f05) at eval.c:2928 #68 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffffa758) at eval.c:2747 #69 0x0000000000630d52 in exec_byte_code (bytestr=41688580, vector=54799629, maxdepth=34, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #70 0x00000000005ef6f1 in funcall_lambda (fun=54799973, nargs=1, arg_vector=0x3442d0d) at eval.c:2928 #71 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffffaca8) at eval.c:2747 #72 0x0000000000630d52 in exec_byte_code (bytestr=41686276, vector=54799229, maxdepth=26, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #73 0x00000000005ef6f1 in funcall_lambda (fun=54799437, nargs=1, arg_vector=0x3442b7d) at eval.c:2928 #74 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffffb1e8) at eval.c:2747 #75 0x0000000000630d52 in exec_byte_code (bytestr=41687076, vector=54799477, maxdepth=10, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #76 0x00000000005ef6f1 in funcall_lambda (fun=54799517, nargs=1, arg_vector=0x3442c75) at eval.c:2928 #77 0x00000000005ef137 in apply_lambda (fun=54799517, args=43886963, count=24) at eval.c:2799 #78 0x00000000005ed9d6 in eval_sub (form=43886947) at eval.c:2216 #79 0x00000000005e9efc in Fprogn (body=43886931) at eval.c:431 #80 0x00000000005ef660 in funcall_lambda (fun=43886899, nargs=1, arg_vector=0x7fffffffb980) at eval.c:2921 #81 0x00000000005eeecb in Ffuncall (nargs=2, args=0x7fffffffb978) at eval.c:2759 #82 0x0000000000630d52 in exec_byte_code (bytestr=22881828, vector=44171061, maxdepth=22, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #83 0x00000000005ef6f1 in funcall_lambda (fun=44171189, nargs=3, arg_vector=0x2a1ff35) at eval.c:2928 #84 0x00000000005eedfa in Ffuncall (nargs=4, args=0x7fffffffbea8) at eval.c:2747 #85 0x0000000000630d52 in exec_byte_code (bytestr=39202884, vector=58046421, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880 #86 0x0000000000630153 in Fbyte_code (bytestr=39202884, vector=58046421, maxdepth=30) at bytecode.c:449 #87 0x00000000005ed82a in eval_sub (form=54684739) at eval.c:2177 #88 0x00000000005eb9f7 in internal_lisp_condition_case (var=9356672, bodyform=54684739, handlers=54684499) at eval.c:1285 #89 0x0000000000631ee7 in exec_byte_code (bytestr=39203140, vector=58046541, maxdepth=14, args_template=0, nargs=0, args=0x0) at bytecode.c:1119 #90 0x00000000005ef6f1 in funcall_lambda (fun=58046597, nargs=0, arg_vector=0x375b84d) at eval.c:2928 #91 0x00000000005eedfa in Ffuncall (nargs=1, args=0x7fffffffcb68) at eval.c:2747 #92 0x00000000005e7151 in Ffuncall_interactively (nargs=1, args=0x7fffffffcb68) at callint.c:252 #93 0x00000000005eea79 in Ffuncall (nargs=2, args=0x7fffffffcb60) at eval.c:2678 #94 0x00000000005edca2 in Fapply (nargs=3, args=0x7fffffffcb60) at eval.c:2279 #95 0x00000000005e75c9 in Fcall_interactively (function=1641232, record_flag=5302080, keys=13460885) at callint.c:389 #96 0x00000000005eebe6 in Ffuncall (nargs=4, args=0x7fffffffcde8) at eval.c:2705 #97 0x0000000000630d52 in exec_byte_code (bytestr=10383612, vector=10383645, maxdepth=54, args_template=4102, nargs=2, args=0x7fffffffd368) at bytecode.c:880 #98 0x00000000005ef3b5 in funcall_lambda (fun=10383565, nargs=2, arg_vector=0x7fffffffd358) at eval.c:2862 #99 0x00000000005eedfa in Ffuncall (nargs=3, args=0x7fffffffd350) at eval.c:2747 #100 0x0000000000630d52 in exec_byte_code (bytestr=10382812, vector=10382845, maxdepth=62, args_template=3078, nargs=3, args=0x7fffffffd9a8) at bytecode.c:880 #101 0x00000000005ef3b5 in funcall_lambda (fun=10382757, nargs=3, arg_vector=0x7fffffffd990) at eval.c:2862 #102 0x00000000005eedfa in Ffuncall (nargs=4, args=0x7fffffffd988) at eval.c:2747 #103 0x00000000005e7151 in Ffuncall_interactively (nargs=4, args=0x7fffffffd988) at callint.c:252 #104 0x00000000005eea79 in Ffuncall (nargs=5, args=0x7fffffffd980) at eval.c:2678 #105 0x00000000005edffe in Fapply (nargs=3, args=0x7fffffffda70) at eval.c:2326 #106 0x00000000005e75c9 in Fcall_interactively (function=673296, record_flag=0, keys=13460885) at callint.c:389 #107 0x00000000005eebe6 in Ffuncall (nargs=4, args=0x7fffffffdcf8) at eval.c:2705 #108 0x0000000000630d52 in exec_byte_code (bytestr=10383612, vector=10383645, maxdepth=54, args_template=4102, nargs=1, args=0x7fffffffe250) at bytecode.c:880 #109 0x00000000005ef3b5 in funcall_lambda (fun=10383565, nargs=1, arg_vector=0x7fffffffe248) at eval.c:2862 #110 0x00000000005eedfa in Ffuncall (nargs=2, args=0x7fffffffe240) at eval.c:2747 #111 0x00000000005ee5a1 in call1 (fn=14832, arg1=673296) at eval.c:2557 #112 0x000000000055482b in command_loop_1 () at keyboard.c:1484 #113 0x00000000005eba83 in internal_condition_case (bfun=0x554075 <command_loop_1>, handlers=19104, hfun=0x553862 <cmd_error>) at eval.c:1314 #114 0x0000000000553d7f in command_loop_2 (ignore=0) at keyboard.c:1112 #115 0x00000000005eb3a3 in internal_catch (tag=45936, func=0x553d56 <command_loop_2>, arg=0) at eval.c:1079 #116 0x0000000000553d21 in command_loop () at keyboard.c:1091 #117 0x000000000055342a in recursive_edit_1 () at keyboard.c:697 #118 0x00000000005535be in Frecursive_edit () at keyboard.c:768 #119 0x0000000000551445 in main (argc=1, argv=0x7fffffffe6f8) at emacs.c:1626 ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; 2016-10-18 8:16 ` bug#24358: 25.1.50; Sam Halliday @ 2016-10-18 8:56 ` Sam Halliday 2016-10-18 9:28 ` Eli Zaretskii 1 sibling, 0 replies; 76+ messages in thread From: Sam Halliday @ 2016-10-18 8:56 UTC (permalink / raw) To: 24358 I've attempted to workaround this in ensime by simplifying our loading of the .ensime file (the s-expression) to use with-temp-buffer and not declaring .ensime as an emacs-lisp file... it may be that one of my minor modes, active in emacs-lisp, is performing a regexp that is triggering this bug. ^ permalink raw reply [flat|nested] 76+ messages in thread
* bug#24358: 25.1.50; 2016-10-18 8:16 ` bug#24358: 25.1.50; Sam Halliday 2016-10-18 8:56 ` Sam Halliday @ 2016-10-18 9:28 ` Eli Zaretskii 1 sibling, 0 replies; 76+ messages in thread From: Eli Zaretskii @ 2016-10-18 9:28 UTC (permalink / raw) To: Sam Halliday; +Cc: 24358 > From: Sam Halliday <sam.halliday@gmail.com> > Date: Tue, 18 Oct 2016 09:16:38 +0100 > > Could somebody please let me know how to dig into 0x56e5508 (if > relevant)? I have never used gdb in anger. The factor that triggers the bug is the call to malloc, which causes relocation of buffer text to a different address, while re_search_2 still uses the (stale) pointer to that text. So the way to make sure this is the same bug is to see that (1) there's a call to malloc between entry to re_search_2 and the crash, and (2) that the value of current_buffer->text->beg is different before and after the call to malloc. Thanks. ^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2016-11-07 15:10 UTC | newest] Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-26 20:17 bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Peder O. Klingenberg 2016-08-27 3:35 ` npostavs 2016-08-30 13:09 ` Peder O. Klingenberg 2016-09-02 1:58 ` npostavs 2016-09-02 13:45 ` Peder O. Klingenberg 2016-09-03 14:21 ` npostavs 2016-09-06 8:18 ` Peder O. Klingenberg 2016-09-07 23:27 ` npostavs 2016-09-03 15:43 ` bug#24358: " npostavs 2016-10-08 0:29 ` npostavs 2016-10-08 5:55 ` Eli Zaretskii 2016-10-08 13:45 ` npostavs 2016-10-08 14:39 ` Eli Zaretskii 2016-10-08 14:47 ` Eli Zaretskii 2016-10-08 16:57 ` npostavs 2016-10-08 17:23 ` Eli Zaretskii 2016-10-08 18:52 ` npostavs 2016-10-08 19:47 ` Eli Zaretskii 2016-10-08 20:55 ` npostavs 2016-10-09 6:52 ` Eli Zaretskii 2016-10-13 1:29 ` npostavs 2016-10-13 6:19 ` Eli Zaretskii 2016-10-14 2:19 ` npostavs 2016-10-14 7:02 ` Eli Zaretskii 2016-10-19 3:11 ` npostavs 2016-10-19 7:02 ` Eli Zaretskii 2016-10-19 12:29 ` npostavs 2016-10-19 14:37 ` Eli Zaretskii 2016-10-20 4:31 ` npostavs 2016-10-20 8:39 ` Eli Zaretskii 2016-10-21 1:22 ` npostavs 2016-10-21 7:17 ` Eli Zaretskii 2016-10-22 2:36 ` npostavs 2016-10-22 21:54 ` Sam Halliday 2016-10-22 22:46 ` npostavs 2016-10-23 6:41 ` Eli Zaretskii 2016-10-23 8:57 ` Sam Halliday 2016-10-23 9:19 ` Eli Zaretskii 2016-10-23 13:40 ` Sam Halliday 2016-10-23 14:07 ` Eli Zaretskii 2016-10-23 15:42 ` Sam Halliday 2016-10-23 15:48 ` Eli Zaretskii 2016-10-23 15:58 ` Sam Halliday 2016-10-23 15:58 ` Sam Halliday 2016-10-23 16:44 ` Eli Zaretskii 2016-10-23 17:19 ` Eli Zaretskii 2016-10-23 18:06 ` Eli Zaretskii 2016-10-23 18:14 ` Noam Postavsky 2016-10-23 19:18 ` Eli Zaretskii 2016-10-24 13:29 ` npostavs 2016-10-24 13:39 ` Eli Zaretskii 2016-10-24 15:33 ` Noam Postavsky 2016-10-24 16:13 ` Eli Zaretskii 2016-10-25 2:00 ` npostavs 2016-10-25 16:03 ` Eli Zaretskii 2016-10-26 0:16 ` npostavs 2016-10-24 13:43 ` Eli Zaretskii 2016-10-24 14:03 ` Eli Zaretskii 2016-10-24 20:13 ` Sam Halliday 2016-10-24 23:44 ` npostavs 2016-11-07 3:39 ` Eli Zaretskii 2016-11-07 3:56 ` Noam Postavsky 2016-11-07 15:10 ` Eli Zaretskii 2016-10-23 18:16 ` Sam Halliday 2016-10-23 19:10 ` Eli Zaretskii 2016-10-23 19:32 ` Eli Zaretskii 2016-10-23 20:15 ` Sam Halliday 2016-10-23 20:27 ` Eli Zaretskii 2016-10-23 20:18 ` Eli Zaretskii 2016-10-23 23:18 ` Noam Postavsky 2016-10-24 7:05 ` Eli Zaretskii 2016-10-24 8:40 ` Eli Zaretskii 2016-10-23 18:11 ` Sam Halliday 2016-10-18 8:16 ` bug#24358: 25.1.50; Sam Halliday 2016-10-18 8:56 ` Sam Halliday 2016-10-18 9:28 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).