GNU bug report logs - #10664
24.0.93; JIT font-lock infloops in a C file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10664 in the body.
You can then email your comments to 10664 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.93; JIT font-lock infloops in a C file
Date: Mon, 30 Jan 2012 20:23:49 +0200

[Message part 1 (text/plain, inline)]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

I don't have a recipe starting from "emacs -Q", sorry.

I left my freshly built Emacs 24.0.93 running, and when I returned to
it a few hours later, I found it unresponsive, endlessly showing in
the echo area "JIT lock socket.c", interspersed with GC messages
(I have garbage-collection-messages set non-nil).

Breaking into Emacs with a debugger produced the backtrace below (it's
an optimized build, so the backtrace may be inaccurate, sorry).  I
attach the file socket.c (part of the Guile sources) as well.

I still have that session in a debugger, so if someone wants me to
look around and show some values, I can do that.

#0  find_symbol_value (symbol=50731778) at data.c:1044
1044          return do_symval_forwarding (SYMBOL_FWD (sym));
(gdb) bt
#0  find_symbol_value (symbol=50731778) at data.c:1044
#1  0x0100fb9b in specbind (symbol=50731778, value=50616370) at eval.c:3322
#2  0x0109f6d5 in exec_byte_code (bytestr=50731778, vector=2,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:747
#3  0x01011a8a in funcall_lambda (fun=69096517, nargs=1, arg_vector=0x82df24)
    at eval.c:3218
#4  0x01011eed in Ffuncall (nargs=2, args=0x41e5445) at eval.c:3048
#5  0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#6  0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
    at bytecode.c:423
#7  0x01011227 in eval_sub (form=20240912) at eval.c:2341
#8  0x0100eef0 in internal_catch (tag=3, func=0x1010ce6 <eval_sub>,
    arg=68864406) at eval.c:1257
#9  0x0109ed60 in exec_byte_code (bytestr=50731778, vector=141,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:966
#10 0x01011a8a in funcall_lambda (fun=68468261, nargs=1, arg_vector=0x82e2d4)
    at eval.c:3218
#11 0x01011eed in Ffuncall (nargs=2, args=0x414be25) at eval.c:3048
#12 0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#13 0x01011a8a in funcall_lambda (fun=69603781, nargs=1, arg_vector=0x82e444)
    at eval.c:3218
#14 0x01011eed in Ffuncall (nargs=2, args=0x42611c5) at eval.c:3048
#15 0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#16 0x01011a8a in funcall_lambda (fun=69603397, nargs=2, arg_vector=0x82e5b4)
    at eval.c:3218
#17 0x01011eed in Ffuncall (nargs=3, args=0x4261045) at eval.c:3048
#18 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#19 0x01011a8a in funcall_lambda (fun=69619589, nargs=1, arg_vector=0x82e72c)
    at eval.c:3218
#20 0x01011eed in Ffuncall (nargs=2, args=0x4264f85) at eval.c:3048
#21 0x0101257a in call1 (fn=3, arg1=3) at eval.c:2756
#22 0x0103162e in mapcar1 (leni=1, vals=0x0, fn=69619589, seq=50731778)
    at fns.c:2346
#23 0x010319d5 in Fmapc (function=3, sequence=71107830) at fns.c:2434
#24 0x010120e8 in Ffuncall (nargs=3, args=0x134acf8) at eval.c:2990
#25 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#26 0x01011a8a in funcall_lambda (fun=69619429, nargs=3, arg_vector=0x82e9e4)
    at eval.c:3218
#27 0x01011eed in Ffuncall (nargs=4, args=0x4264ee5) at eval.c:3048
#28 0x0109f68c in exec_byte_code (bytestr=50731778, vector=3,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#29 0x01011a8a in funcall_lambda (fun=19193997, nargs=2, arg_vector=0x82ec68)
    at eval.c:3218
#30 0x01011eed in Ffuncall (nargs=3, args=0x124e08d) at eval.c:3048
#31 0x01012618 in funcall_nil (nargs=3, args=0x3) at eval.c:2504
#32 0x0100f5af in run_hook_with_args (nargs=3, args=0x82ec64,
    funcall=0x1012600 <funcall_nil>) at eval.c:2693
#33 0x0100f6f3 in Frun_hook_with_args (nargs=3, args=0x3) at eval.c:2554
#34 0x01012184 in Ffuncall (nargs=4, args=0x134a01d) at eval.c:2969
#35 0x0109f68c in exec_byte_code (bytestr=50731778, vector=3,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#36 0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
    at bytecode.c:423
#37 0x01011227 in eval_sub (form=20240912) at eval.c:2341
#38 0x01012fbf in internal_lisp_condition_case (var=50869346,
    bodyform=19206126, handlers=19206174) at eval.c:1454
#39 0x0109ed1e in exec_byte_code (bytestr=50731778, vector=143,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:981
#40 0x01011a8a in funcall_lambda (fun=19205877, nargs=2, arg_vector=0x82f034)
    at eval.c:3218
#41 0x01011eed in Ffuncall (nargs=3, args=0x1250ef5) at eval.c:3048
#42 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#43 0x01011a8a in funcall_lambda (fun=19206717, nargs=1, arg_vector=0x82f278)
    at eval.c:3218
#44 0x01011eed in Ffuncall (nargs=2, args=0x125123d) at eval.c:3048
#45 0x0101275e in Fapply (nargs=2, args=0x82f274) at eval.c:2439
#46 0x01012184 in Ffuncall (nargs=3, args=0x134a065) at eval.c:2969
#47 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:785
#48 0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
    at bytecode.c:423
#49 0x01011227 in eval_sub (form=20240912) at eval.c:2341
#50 0x01012fbf in internal_lisp_condition_case (var=50616346,
    bodyform=19235438, handlers=18612686) at eval.c:1454
#51 0x0109ed1e in exec_byte_code (bytestr=50731778, vector=143,
    maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
    at bytecode.c:981
#52 0x01011a8a in funcall_lambda (fun=19235277, nargs=1, arg_vector=0x82f64c)
    at eval.c:3218
#53 0x01011eed in Ffuncall (nargs=2, args=0x12581cd) at eval.c:3048
#54 0x0101257a in call1 (fn=3, arg1=3) at eval.c:2756
#55 0x0101e391 in timer_check () at keyboard.c:4437
#56 0x0101e5c2 in readable_events (flags=1) at keyboard.c:3388
#57 0x010244ad in get_input_pending (addr=0x13c51b0, flags=1)
    at keyboard.c:6713
#58 0x01024562 in detect_input_pending_run_timers (do_display=1)
    at keyboard.c:10480
#59 0x0101984b in wait_reading_process_output (time_limit=0, microsecs=0,
    read_kbd=-1, do_display=1, wait_for_cell=50616346, wait_proc=0x0,
    just_wait_proc=0) at process.c:4733
#60 0x01025c6a in read_char (commandflag=1, nmaps=2, maps=0x82fab0,
    prev_event=50616346, used_mouse_menu=0x82fbb8, end_time=0x0)
    at keyboard.c:3851
#61 0x01027b26 in read_key_sequence (keybuf=0x82fcb0, bufsize=30,
    prompt=50616346, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9300
#62 0x01029a9f in command_loop_1 () at keyboard.c:1448
#63 0x0100efbb in internal_condition_case (bfun=0x10298ff <command_loop_1>,
    handlers=50674074, hfun=0x102374d <cmd_error>) at eval.c:1500
#64 0x0101cf0f in command_loop_2 (ignore=50616346) at keyboard.c:1159
#65 0x0100eef0 in internal_catch (tag=3, func=0x101ceec <command_loop_2>,
    arg=50616346) at eval.c:1257
#66 0x0101cdc2 in recursive_edit_1 () at keyboard.c:1138
#67 0x0101ced6 in Frecursive_edit () at keyboard.c:822
#68 0x01002f21 in main (argc=1, argv=0xa47ff0) at emacs.c:1715

Lisp Backtrace:
"c-in-knr-argdecl" (0x82df24)
"byte-code" (0x82e030)
"c-beginning-of-decl-1" (0x82e2d4)
"c-set-fl-decl-start" (0x82e444)
"c-context-set-fl-decl-start" (0x82e5b4)
0x4264f80 PVEC_COMPILED
"mapc" (0x82e874)
"c-font-lock-fontify-region" (0x82e9e4)
"font-lock-fontify-region" (0x82ec68)
"run-hook-with-args" (0x82ec64)
"byte-code" (0x82ed60)
"jit-lock-fontify-now" (0x82f034)
"jit-lock-stealth-fontify" (0x82f278)
"apply" (0x82f274)
"byte-code" (0x82f370)
"timer-event-handler" (0x82f64c)
(gdb) p symbol
$1 = 50731778
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x3061b00
"buffer-undo-list"
(gdb)



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/usr/emacs/etc/DEBUG.


In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-01-29 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  flyspell-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
<delete> <delete> <delete> <delete> <delete> <delete> 
<delete> <delete> <delete> <delete> t h e SPC o t h 
e r SPC p o s s i b l e SPC r e a s i n SPC <backspace> 
<backspace> <backspace> o n SPC i s SPC t h a t M-q 
<C-right> <C-right> <C-right> M-d <C-right> <C-right> 
SPC ( n o t SPC i n s t a l l e d ) M-q <down> <down> 
<C-home> C-c C-s <switch-frame> d SPC M-z M-z M-z M-z 
M-z M-z M-z M-z M-z M-z M-z M-z M-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z M-z n o G N 
U W <tab> <return> SPC M-z n d SPC SPC d SPC d p p 
p p p p p p n n n n n C-z C-z C-z C-z C-z C-z C-z C-z 
<switch-frame> <help-echo> <switch-frame> <help-echo> 
<switch-frame> <switch-frame> <C-home> f n e s s SPC 
<backspace> <down> <down> <down> <down> <down> C h 
e c k SPC t h i s SPC o u t . C-c C-s C-g C-x 1 <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> C-x <return> f <return> C-c C-s <switch-frame> 
n SPC o P O <tab> <return> SPC n p p p p p p p p p 
p p p n n n n n n n n n n n n n n n n n n n n n n n 
n n n n <help-echo> <switch-frame> <help-echo> <help-echo> 
<help-echo> <help-echo> <switch-frame> C-x C-s <switch-frame> 
M-x r e p o r t - e m <tab> <return>

Recent messages:
Quit
Sending...
Added to d:/usr/eli/rmail/SENT.MAIL
Sending email 
Sending email done
Sending...done
Added to d:/usr/eli/rmail/PORTS.rmail
No following nondeleted message [16 times]
Saving file d:/usr/eli/rmail/INBOX...
Wrote d:/usr/eli/rmail/INBOX [2 times]

Load-path shadows:
None found.

Features:
(shadow emacsbug find-func multi-isearch help-mode view dabbrev
network-stream starttls tls smtpmail auth-source eieio assoc gnus-util
password-cache mailalias sendmail rmailout ld-script sh-script
executable dired-x dired tcl nxml-uchnm rng-xsd xsd-regexp rng-cmpct
rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match
rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap
nxml-util nxml-glyph nxml-enc xmltok sgml-mode org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html
org-exp ob-exp org-exp-blocks org-agenda org-info org-gnus org-docview
org-bibtex bibtex org-bbdb org byte-opt warnings bytecomp byte-compile
cconv macroexp advice help-fns advice-preload ob-emacs-lisp ob-tangle
ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob
ob-eval org-pcomplete pcomplete comint ring org-list org-faces
org-compat org-entities org-macs cal-menu calendar cal-loaddefs
noutline outline arc-mode archive-mode jka-compr flyspell ispell
autorevert diff-mode easy-mmode make-mode conf-mode newcomment generic
parse-time vc-cvs info vc-bzr cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
rmailsum qp rmailmm message format-spec rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils desktop server filecache saveplace midnight generic-x paren
battery time time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)

[socket.c (application/octet-stream, attachment)]

Message #8 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Sun, 05 Feb 2012 20:18:58 +0200

> Date: Mon, 30 Jan 2012 20:23:49 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>

Ping!

> This bug report will be sent to the Bug-GNU-Emacs mailing list
> and the GNU bug tracker at debbugs.gnu.org.  Please check that
> the From: line contains a valid email address.  After a delay of up
> to one day, you should receive an acknowledgement at that address.
> 
> Please write in English if possible, as the Emacs maintainers
> usually do not have translators for other languages.
> 
> Please describe exactly what actions triggered the bug, and
> the precise symptoms of the bug.  If you can, give a recipe
> starting from `emacs -Q':
> 
> I don't have a recipe starting from "emacs -Q", sorry.
> 
> I left my freshly built Emacs 24.0.93 running, and when I returned to
> it a few hours later, I found it unresponsive, endlessly showing in
> the echo area "JIT lock socket.c", interspersed with GC messages
> (I have garbage-collection-messages set non-nil).
> 
> Breaking into Emacs with a debugger produced the backtrace below (it's
> an optimized build, so the backtrace may be inaccurate, sorry).  I
> attach the file socket.c (part of the Guile sources) as well.
> 
> I still have that session in a debugger, so if someone wants me to
> look around and show some values, I can do that.
> 
> #0  find_symbol_value (symbol=50731778) at data.c:1044
> 1044          return do_symval_forwarding (SYMBOL_FWD (sym));
> (gdb) bt
> #0  find_symbol_value (symbol=50731778) at data.c:1044
> #1  0x0100fb9b in specbind (symbol=50731778, value=50616370) at eval.c:3322
> #2  0x0109f6d5 in exec_byte_code (bytestr=50731778, vector=2,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:747
> #3  0x01011a8a in funcall_lambda (fun=69096517, nargs=1, arg_vector=0x82df24)
>     at eval.c:3218
> #4  0x01011eed in Ffuncall (nargs=2, args=0x41e5445) at eval.c:3048
> #5  0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #6  0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
>     at bytecode.c:423
> #7  0x01011227 in eval_sub (form=20240912) at eval.c:2341
> #8  0x0100eef0 in internal_catch (tag=3, func=0x1010ce6 <eval_sub>,
>     arg=68864406) at eval.c:1257
> #9  0x0109ed60 in exec_byte_code (bytestr=50731778, vector=141,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:966
> #10 0x01011a8a in funcall_lambda (fun=68468261, nargs=1, arg_vector=0x82e2d4)
>     at eval.c:3218
> #11 0x01011eed in Ffuncall (nargs=2, args=0x414be25) at eval.c:3048
> #12 0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #13 0x01011a8a in funcall_lambda (fun=69603781, nargs=1, arg_vector=0x82e444)
>     at eval.c:3218
> #14 0x01011eed in Ffuncall (nargs=2, args=0x42611c5) at eval.c:3048
> #15 0x0109f68c in exec_byte_code (bytestr=50731778, vector=1,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #16 0x01011a8a in funcall_lambda (fun=69603397, nargs=2, arg_vector=0x82e5b4)
>     at eval.c:3218
> #17 0x01011eed in Ffuncall (nargs=3, args=0x4261045) at eval.c:3048
> #18 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #19 0x01011a8a in funcall_lambda (fun=69619589, nargs=1, arg_vector=0x82e72c)
>     at eval.c:3218
> #20 0x01011eed in Ffuncall (nargs=2, args=0x4264f85) at eval.c:3048
> #21 0x0101257a in call1 (fn=3, arg1=3) at eval.c:2756
> #22 0x0103162e in mapcar1 (leni=1, vals=0x0, fn=69619589, seq=50731778)
>     at fns.c:2346
> #23 0x010319d5 in Fmapc (function=3, sequence=71107830) at fns.c:2434
> #24 0x010120e8 in Ffuncall (nargs=3, args=0x134acf8) at eval.c:2990
> #25 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #26 0x01011a8a in funcall_lambda (fun=69619429, nargs=3, arg_vector=0x82e9e4)
>     at eval.c:3218
> #27 0x01011eed in Ffuncall (nargs=4, args=0x4264ee5) at eval.c:3048
> #28 0x0109f68c in exec_byte_code (bytestr=50731778, vector=3,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #29 0x01011a8a in funcall_lambda (fun=19193997, nargs=2, arg_vector=0x82ec68)
>     at eval.c:3218
> #30 0x01011eed in Ffuncall (nargs=3, args=0x124e08d) at eval.c:3048
> #31 0x01012618 in funcall_nil (nargs=3, args=0x3) at eval.c:2504
> #32 0x0100f5af in run_hook_with_args (nargs=3, args=0x82ec64,
>     funcall=0x1012600 <funcall_nil>) at eval.c:2693
> #33 0x0100f6f3 in Frun_hook_with_args (nargs=3, args=0x3) at eval.c:2554
> #34 0x01012184 in Ffuncall (nargs=4, args=0x134a01d) at eval.c:2969
> #35 0x0109f68c in exec_byte_code (bytestr=50731778, vector=3,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #36 0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
>     at bytecode.c:423
> #37 0x01011227 in eval_sub (form=20240912) at eval.c:2341
> #38 0x01012fbf in internal_lisp_condition_case (var=50869346,
>     bodyform=19206126, handlers=19206174) at eval.c:1454
> #39 0x0109ed1e in exec_byte_code (bytestr=50731778, vector=143,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:981
> #40 0x01011a8a in funcall_lambda (fun=19205877, nargs=2, arg_vector=0x82f034)
>     at eval.c:3218
> #41 0x01011eed in Ffuncall (nargs=3, args=0x1250ef5) at eval.c:3048
> #42 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #43 0x01011a8a in funcall_lambda (fun=19206717, nargs=1, arg_vector=0x82f278)
>     at eval.c:3218
> #44 0x01011eed in Ffuncall (nargs=2, args=0x125123d) at eval.c:3048
> #45 0x0101275e in Fapply (nargs=2, args=0x82f274) at eval.c:2439
> #46 0x01012184 in Ffuncall (nargs=3, args=0x134a065) at eval.c:2969
> #47 0x0109f68c in exec_byte_code (bytestr=50731778, vector=2,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:785
> #48 0x0109ff82 in Fbyte_code (bytestr=3, vector=3, maxdepth=3)
>     at bytecode.c:423
> #49 0x01011227 in eval_sub (form=20240912) at eval.c:2341
> #50 0x01012fbf in internal_lisp_condition_case (var=50616346,
>     bodyform=19235438, handlers=18612686) at eval.c:1454
> #51 0x0109ed1e in exec_byte_code (bytestr=50731778, vector=143,
>     maxdepth=50731776, args_template=50616346, nargs=0, args=0x0)
>     at bytecode.c:981
> #52 0x01011a8a in funcall_lambda (fun=19235277, nargs=1, arg_vector=0x82f64c)
>     at eval.c:3218
> #53 0x01011eed in Ffuncall (nargs=2, args=0x12581cd) at eval.c:3048
> #54 0x0101257a in call1 (fn=3, arg1=3) at eval.c:2756
> #55 0x0101e391 in timer_check () at keyboard.c:4437
> #56 0x0101e5c2 in readable_events (flags=1) at keyboard.c:3388
> #57 0x010244ad in get_input_pending (addr=0x13c51b0, flags=1)
>     at keyboard.c:6713
> #58 0x01024562 in detect_input_pending_run_timers (do_display=1)
>     at keyboard.c:10480
> #59 0x0101984b in wait_reading_process_output (time_limit=0, microsecs=0,
>     read_kbd=-1, do_display=1, wait_for_cell=50616346, wait_proc=0x0,
>     just_wait_proc=0) at process.c:4733
> #60 0x01025c6a in read_char (commandflag=1, nmaps=2, maps=0x82fab0,
>     prev_event=50616346, used_mouse_menu=0x82fbb8, end_time=0x0)
>     at keyboard.c:3851
> #61 0x01027b26 in read_key_sequence (keybuf=0x82fcb0, bufsize=30,
>     prompt=50616346, dont_downcase_last=0, can_return_switch_frame=1,
>     fix_current_buffer=1) at keyboard.c:9300
> #62 0x01029a9f in command_loop_1 () at keyboard.c:1448
> #63 0x0100efbb in internal_condition_case (bfun=0x10298ff <command_loop_1>,
>     handlers=50674074, hfun=0x102374d <cmd_error>) at eval.c:1500
> #64 0x0101cf0f in command_loop_2 (ignore=50616346) at keyboard.c:1159
> #65 0x0100eef0 in internal_catch (tag=3, func=0x101ceec <command_loop_2>,
>     arg=50616346) at eval.c:1257
> #66 0x0101cdc2 in recursive_edit_1 () at keyboard.c:1138
> #67 0x0101ced6 in Frecursive_edit () at keyboard.c:822
> #68 0x01002f21 in main (argc=1, argv=0xa47ff0) at emacs.c:1715
> 
> Lisp Backtrace:
> "c-in-knr-argdecl" (0x82df24)
> "byte-code" (0x82e030)
> "c-beginning-of-decl-1" (0x82e2d4)
> "c-set-fl-decl-start" (0x82e444)
> "c-context-set-fl-decl-start" (0x82e5b4)
> 0x4264f80 PVEC_COMPILED
> "mapc" (0x82e874)
> "c-font-lock-fontify-region" (0x82e9e4)
> "font-lock-fontify-region" (0x82ec68)
> "run-hook-with-args" (0x82ec64)
> "byte-code" (0x82ed60)
> "jit-lock-fontify-now" (0x82f034)
> "jit-lock-stealth-fontify" (0x82f278)
> "apply" (0x82f274)
> "byte-code" (0x82f370)
> "timer-event-handler" (0x82f64c)
> (gdb) p symbol
> $1 = 50731778
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0x3061b00
> "buffer-undo-list"
> (gdb)
> 
> 
> 
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> For information about debugging Emacs, please read the file
> d:/usr/emacs/etc/DEBUG.
> 
> 
> In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
>  of 2012-01-29 on HOME-C4E4A596F7
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> Configured using:
>  `configure --with-gcc (3.4)'
> 
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   value of $XMODIFIERS: nil
>   locale-coding-system: cp1255
>   default enable-multibyte-characters: t
> 
> Major mode: Mail
> 
> Minor modes in effect:
>   flyspell-mode: t
>   diff-auto-refine-mode: t
>   desktop-save-mode: t
>   show-paren-mode: t
>   display-time-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   temp-buffer-resize-mode: t
>   line-number-mode: t
>   abbrev-mode: t
> 
> Recent input:
> <delete> <delete> <delete> <delete> <delete> <delete> 
> <delete> <delete> <delete> <delete> t h e SPC o t h 
> e r SPC p o s s i b l e SPC r e a s i n SPC <backspace> 
> <backspace> <backspace> o n SPC i s SPC t h a t M-q 
> <C-right> <C-right> <C-right> M-d <C-right> <C-right> 
> SPC ( n o t SPC i n s t a l l e d ) M-q <down> <down> 
> <C-home> C-c C-s <switch-frame> d SPC M-z M-z M-z M-z 
> M-z M-z M-z M-z M-z M-z M-z M-z M-z C-z C-z C-z C-z 
> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z M-z n o G N 
> U W <tab> <return> SPC M-z n d SPC SPC d SPC d p p 
> p p p p p p n n n n n C-z C-z C-z C-z C-z C-z C-z C-z 
> <switch-frame> <help-echo> <switch-frame> <help-echo> 
> <switch-frame> <switch-frame> <C-home> f n e s s SPC 
> <backspace> <down> <down> <down> <down> <down> C h 
> e c k SPC t h i s SPC o u t . C-c C-s C-g C-x 1 <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> C-x <return> f <return> C-c C-s <switch-frame> 
> n SPC o P O <tab> <return> SPC n p p p p p p p p p 
> p p p n n n n n n n n n n n n n n n n n n n n n n n 
> n n n n <help-echo> <switch-frame> <help-echo> <help-echo> 
> <help-echo> <help-echo> <switch-frame> C-x C-s <switch-frame> 
> M-x r e p o r t - e m <tab> <return>
> 
> Recent messages:
> Quit
> Sending...
> Added to d:/usr/eli/rmail/SENT.MAIL
> Sending email 
> Sending email done
> Sending...done
> Added to d:/usr/eli/rmail/PORTS.rmail
> No following nondeleted message [16 times]
> Saving file d:/usr/eli/rmail/INBOX...
> Wrote d:/usr/eli/rmail/INBOX [2 times]
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow emacsbug find-func multi-isearch help-mode view dabbrev
> network-stream starttls tls smtpmail auth-source eieio assoc gnus-util
> password-cache mailalias sendmail rmailout ld-script sh-script
> executable dired-x dired tcl nxml-uchnm rng-xsd xsd-regexp rng-cmpct
> rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match
> rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap
> nxml-util nxml-glyph nxml-enc xmltok sgml-mode org-wl org-w3m org-vm
> org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html
> org-exp ob-exp org-exp-blocks org-agenda org-info org-gnus org-docview
> org-bibtex bibtex org-bbdb org byte-opt warnings bytecomp byte-compile
> cconv macroexp advice help-fns advice-preload ob-emacs-lisp ob-tangle
> ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob
> ob-eval org-pcomplete pcomplete comint ring org-list org-faces
> org-compat org-entities org-macs cal-menu calendar cal-loaddefs
> noutline outline arc-mode archive-mode jka-compr flyspell ispell
> autorevert diff-mode easy-mmode make-mode conf-mode newcomment generic
> parse-time vc-cvs info vc-bzr cc-mode cc-fonts cc-guess cc-menus
> cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
> rmailsum qp rmailmm message format-spec rfc822 mml easymenu mml-sec
> mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
> mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
> mail-utils desktop server filecache saveplace midnight generic-x paren
> battery time time-date tooltip ediff-hook vc-hooks lisp-float-type
> mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd
> fontset image fringe lisp-mode register page menu-bar rfn-eshadow
> timer select scroll-bar mouse jit-lock font-lock syntax facemenu
> font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
> thai tai-viet lao korean japanese hebrew greek romanian slovak czech
> european ethiopic indian cyrillic chinese case-table epa-hook
> jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
> cus-face files text-properties overlay sha1 md5 base64 format env
> code-pages mule custom widget hashtable-print-readable backquote
> make-network-process multi-tty emacs)
> 
> 
> [2:application/octet-stream Show Save:socket.c (55kB)]
> 

Message #11 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Mon, 6 Feb 2012 11:09:57 +0000

Hi, Eli.

On Sun, Feb 05, 2012 at 08:18:58PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 30 Jan 2012 20:23:49 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>

> > I don't have a recipe starting from "emacs -Q", sorry.

> > I left my freshly built Emacs 24.0.93 running, and when I returned to
> > it a few hours later, I found it unresponsive, endlessly showing in
> > the echo area "JIT lock socket.c", interspersed with GC messages
> > (I have garbage-collection-messages set non-nil).

> > Breaking into Emacs with a debugger produced the backtrace below (it's
> > an optimized build, so the backtrace may be inaccurate, sorry).  I
> > attach the file socket.c (part of the Guile sources) as well.

I got something similar for this socket.c.  I load it into emacs -Q, then
start scrolling downwards, a page at a time.  The first five scrolls are
fine.  Then it hangs on the sixth.

However, typing C-g (maybe twice) frees it up, and it does the scroll.
Careful perusal reveals that the fontification is incomplete.  From now
on, most key sequences must be followed by C-g to perform their commands.
;-(.

Did you actually try C-g when your session hung?

I was able to run elp on this, and I've a fairly good idea where it's got
stuck, but not yet why.

> > I still have that session in a debugger, so if someone wants me to
> > look around and show some values, I can do that.

I'm not sure I'd be able to make much out of debugger results.  I'm not
familiar enough with the internals of Emacs.  :-(

Can you restart this Emacs session?  If so, could you try out C-g
(assuming you haven't already done so).

> > Lisp Backtrace:
> > "c-in-knr-argdecl" (0x82df24)
> > "byte-code" (0x82e030)
> > "c-beginning-of-decl-1" (0x82e2d4)
> > "c-set-fl-decl-start" (0x82e444)
> > "c-context-set-fl-decl-start" (0x82e5b4)
> > 0x4264f80 PVEC_COMPILED
> > "mapc" (0x82e874)
> > "c-font-lock-fontify-region" (0x82e9e4)
> > "font-lock-fontify-region" (0x82ec68)
> > "run-hook-with-args" (0x82ec64)
> > "byte-code" (0x82ed60)
> > "jit-lock-fontify-now" (0x82f034)
> > "jit-lock-stealth-fontify" (0x82f278)
> > "apply" (0x82f274)
> > "byte-code" (0x82f370)
> > "timer-event-handler" (0x82f64c)
> > (gdb) p symbol
> > $1 = 50731778
> > (gdb) xtype
> > Lisp_Symbol
> > (gdb) xsymbol
> > $2 = (struct Lisp_Symbol *) 0x3061b00
> > "buffer-undo-list"
> > (gdb)

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #14 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Mon, 06 Feb 2012 09:39:26 -0500

>> > I don't have a recipe starting from "emacs -Q", sorry.

>> > I left my freshly built Emacs 24.0.93 running, and when I returned to
>> > it a few hours later, I found it unresponsive, endlessly showing in
>> > the echo area "JIT lock socket.c", interspersed with GC messages
>> > (I have garbage-collection-messages set non-nil).

>> > Breaking into Emacs with a debugger produced the backtrace below (it's
>> > an optimized build, so the backtrace may be inaccurate, sorry).  I
>> > attach the file socket.c (part of the Guile sources) as well.

> I got something similar for this socket.c.  I load it into emacs -Q, then
> start scrolling downwards, a page at a time.  The first five scrolls are
> fine.  Then it hangs on the sixth.

While not easy, it should be theoretically possible to reproduce the
problem with (setq font-lock-support-mode nil) which would make it much
easier to debug.  If the problem doesn't appear right when enabling
font-lock, then it needs to be triggered by cutting and re-inserting
a chunk of text (and you need to find a chunk that triggers the problem).


        Stefan

Message #17 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Mon, 06 Feb 2012 19:04:17 +0200

> Date: Mon, 6 Feb 2012 11:09:57 +0000
> Cc: 10664 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> I got something similar for this socket.c.  I load it into emacs -Q, then
> start scrolling downwards, a page at a time.  The first five scrolls are
> fine.  Then it hangs on the sixth.
> 
> However, typing C-g (maybe twice) frees it up, and it does the scroll.
> Careful perusal reveals that the fontification is incomplete.  From now
> on, most key sequences must be followed by C-g to perform their commands.
> ;-(.
> 
> Did you actually try C-g when your session hung?

I'm quite sure I did.  But that was on Windows, where C-g is less
powerful than on Posix platforms (since keyboard input is not
interrupt driven).  So it could be that what you can interrupt on
GNU/Linux, I cannot on Windows.

> I was able to run elp on this, and I've a fairly good idea where it's got
> stuck, but not yet why.

Let me know if you need any further help.

> > > I still have that session in a debugger, so if someone wants me to
> > > look around and show some values, I can do that.
> 
> I'm not sure I'd be able to make much out of debugger results.  I'm not
> familiar enough with the internals of Emacs.  :-(

That's good, because I needed to kill that session in order to rebuild
Emacs.

> Can you restart this Emacs session?

No, but I can start another and do the same (i.e. wait for it to hang
in the same way).  The problem is reproducible in my configuration.
But I think it would be better to wait for you to fix that problem you
are zeroing in, and then see if it also fixes my hangs.

Thanks.

Message #20 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: acm <at> muc.de, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 07 Feb 2012 19:30:17 +0200

> Date: Mon, 06 Feb 2012 19:04:17 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 10664 <at> debbugs.gnu.org
> 
> > Date: Mon, 6 Feb 2012 11:09:57 +0000
> > Cc: 10664 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>
> > 
> > I got something similar for this socket.c.  I load it into emacs -Q, then
> > start scrolling downwards, a page at a time.  The first five scrolls are
> > fine.  Then it hangs on the sixth.
> > 
> > However, typing C-g (maybe twice) frees it up, and it does the scroll.
> > Careful perusal reveals that the fontification is incomplete.  From now
> > on, most key sequences must be followed by C-g to perform their commands.
> > ;-(.
> > 
> > Did you actually try C-g when your session hung?
> 
> I'm quite sure I did.  But that was on Windows, where C-g is less
> powerful than on Posix platforms (since keyboard input is not
> interrupt driven).  So it could be that what you can interrupt on
> GNU/Linux, I cannot on Windows.

I'm now absolutely sure this is the case: the offending code runs with
inhibit-quit set, and that prevents Emacs on Windows from interrupting
that code.  I know because attaching GDB and using the debugger to set
inhibit-quit to nil breaks the vicious circle and let me salvage my
session without killing Emacs.

Btw, this time the problem happened with main.c from the recent Gawk
4.0.0h pre-release.

Message #23 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 7 Feb 2012 19:20:33 +0000

Hi, Eli.

I've done a binary chop on this, and the following revision made this bug
apparent:

revno: 106729
committer: Alan Mackenzie <acm <at> muc.de>
branch nick: trunk
timestamp: Sat 2011-12-24 19:32:31 +0000
message:
  Introduce a mechanism to widen the region used in context font locking.
  Use this to protect declarations from losing their contexts.

I'll see what I can work out from this.  At least it's one of mine.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).


On Mon, Feb 06, 2012 at 07:04:17PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 6 Feb 2012 11:09:57 +0000
> > Cc: 10664 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > I got something similar for this socket.c.  I load it into emacs -Q, then
> > start scrolling downwards, a page at a time.  The first five scrolls are
> > fine.  Then it hangs on the sixth.

> > However, typing C-g (maybe twice) frees it up, and it does the scroll.
> > Careful perusal reveals that the fontification is incomplete.  From now
> > on, most key sequences must be followed by C-g to perform their commands.
> > ;-(.

> > Did you actually try C-g when your session hung?

> I'm quite sure I did.  But that was on Windows, where C-g is less
> powerful than on Posix platforms (since keyboard input is not
> interrupt driven).  So it could be that what you can interrupt on
> GNU/Linux, I cannot on Windows.

> > I was able to run elp on this, and I've a fairly good idea where it's got
> > stuck, but not yet why.

> Let me know if you need any further help.

> > > > I still have that session in a debugger, so if someone wants me to
> > > > look around and show some values, I can do that.

> > I'm not sure I'd be able to make much out of debugger results.  I'm not
> > familiar enough with the internals of Emacs.  :-(

> That's good, because I needed to kill that session in order to rebuild
> Emacs.

> > Can you restart this Emacs session?

> No, but I can start another and do the same (i.e. wait for it to hang
> in the same way).  The problem is reproducible in my configuration.
> But I think it would be better to wait for you to fix that problem you
> are zeroing in, and then see if it also fixes my hangs.

> Thanks.

Message #26 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 07 Feb 2012 22:58:09 +0200

> Date: Tue, 7 Feb 2012 19:20:33 +0000
> Cc: 10664 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> I've done a binary chop on this, and the following revision made this bug
> apparent:
> 
> revno: 106729
> committer: Alan Mackenzie <acm <at> muc.de>
> branch nick: trunk
> timestamp: Sat 2011-12-24 19:32:31 +0000
> message:
>   Introduce a mechanism to widen the region used in context font locking.
>   Use this to protect declarations from losing their contexts.
> 
> I'll see what I can work out from this.  At least it's one of mine.  ;-)

Great, thanks.

Message #29 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 7 Feb 2012 21:34:01 +0000

Hello, Eli.

On Tue, Feb 07, 2012 at 10:58:09PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 7 Feb 2012 19:20:33 +0000
> > Cc: 10664 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > I've done a binary chop on this, and the following revision made this bug
> > apparent:

> > revno: 106729
> > committer: Alan Mackenzie <acm <at> muc.de>
> > branch nick: trunk
> > timestamp: Sat 2011-12-24 19:32:31 +0000
> > message:
> >   Introduce a mechanism to widen the region used in context font locking.
> >   Use this to protect declarations from losing their contexts.

> > I'll see what I can work out from this.  At least it's one of mine.  ;-)

> Great, thanks.

I understand what's happening, now.  The new code (from 2011-12-24),
given a point, is calculating a "safe" position backwards from that point
to start fontifying from.  This is a position which gives the correct
context for the original point.

For one particular fontification in socket.c, the "safe position" is 500
bytes back from the starting point, so jit-lock is pushed back these 500
bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
new start position set back 500 bytes, rinse, spin, repeat.

I don't understand yet why this isn't happening a lot more frequently.
I think it's got something to do with the safe position being _exactly_
500 bytes back.

I don't know what to do about this yet, but I'll think of something.

Good night!

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #32 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 07 Feb 2012 18:39:11 -0500

> For one particular fontification in socket.c, the "safe position" is 500
> bytes back from the starting point, so jit-lock is pushed back these 500
> bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
> new start position set back 500 bytes, rinse, spin, repeat.

Why is "jit-lock pushed back"?


        Stefan

Message #35 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Wed, 8 Feb 2012 11:47:49 +0000

Hi, Stefan.

On Tue, Feb 07, 2012 at 06:39:11PM -0500, Stefan Monnier wrote:
> > For one particular fontification in socket.c, the "safe position" is 500
> > bytes back from the starting point, so jit-lock is pushed back these 500
> > bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
> > new start position set back 500 bytes, rinse, spin, repeat.

> Why is "jit-lock pushed back"?

Build Emacs revision #106728.  emacs -Q, then create the following C++
buffer:

#########################################################################
1 template <typename T>
2
3
4 void myfunc(T* p) {}
#########################################################################

This is fontified correctly.  Type a space on L2.  This is OK for half a
second, then context fontification messes up L4.  The correct
fontification can only be restored by a change to L4.

Revision #106729 fixes this problem, after a space on L2, by making the
fontification start at L1 rather than L2.

The exact mechanism of why the problem happened is buried in my log, and
I could dredge it up if you're really interested.

The problem with this approach is demonstrated in Eli's socket.c:

SCM_DEFINE (scm_inet_pton, "inet-pton", 2, 0, 0,
            (SCM family, SCM address),
            "Convert a string containing a printable network address to\n"
            "an integer address.  Note that unlike the C version of this\n"
            "function,\n"
            "the result is an integer with normal host byte ordering.\n"
            "@var{family} can be @code{AF_INET} or @code{AF_INET6}.  E.g.,\n\n"
            "@lisp\n"
            "(inet-pton AF_INET \"127.0.0.1\") @result{} 2130706433\n"
            "(inet-pton AF_INET6 \"::1\") @result{} 1\n"
            "@end lisp")
#define FUNC_NAME s_scm_inet_pton
{

A 500 byte chunk of fontification ends just before "@end lisp".  For
this line, the start of the next chunk is "pushed back" to the
SCM_DEFINE line to get a proper context for "@end lisp".  It then
repeatedly fontifies the same chunk.

Interestingly, EOL just before "@end lisp" is exactly 500 bytes after
the initial scm_inet_pton.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #38 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10664 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Wed, 08 Feb 2012 19:49:58 +0200

> Date: Wed, 8 Feb 2012 11:47:49 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 10664 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> #########################################################################
> 1 template <typename T>
> 2
> 3
> 4 void myfunc(T* p) {}
> #########################################################################
> 
> This is fontified correctly.  Type a space on L2.  This is OK for half a
> second, then context fontification messes up L4.  The correct
> fontification can only be restored by a change to L4.
> 
> Revision #106729 fixes this problem, after a space on L2, by making the
> fontification start at L1 rather than L2.
> 
> The exact mechanism of why the problem happened is buried in my log, and
> I could dredge it up if you're really interested.
> 
> The problem with this approach is demonstrated in Eli's socket.c:
> 
> SCM_DEFINE (scm_inet_pton, "inet-pton", 2, 0, 0,
>             (SCM family, SCM address),
>             "Convert a string containing a printable network address to\n"
>             "an integer address.  Note that unlike the C version of this\n"
>             "function,\n"
>             "the result is an integer with normal host byte ordering.\n"
>             "@var{family} can be @code{AF_INET} or @code{AF_INET6}.  E.g.,\n\n"
>             "@lisp\n"
>             "(inet-pton AF_INET \"127.0.0.1\") @result{} 2130706433\n"
>             "(inet-pton AF_INET6 \"::1\") @result{} 1\n"
>             "@end lisp")
> #define FUNC_NAME s_scm_inet_pton
> {
> 
> A 500 byte chunk of fontification ends just before "@end lisp".  For
> this line, the start of the next chunk is "pushed back" to the
> SCM_DEFINE line to get a proper context for "@end lisp".  It then
> repeatedly fontifies the same chunk.
> 
> Interestingly, EOL just before "@end lisp" is exactly 500 bytes after
> the initial scm_inet_pton.

Thanks for explaining this.

Would it fix the problem if, when jit-lock is "pushed back" by N >= 500
characters, it will fontify N + n characters, where n > 0 ?  (E.g., set
n = 100.)

Message #41 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Wed, 08 Feb 2012 14:28:53 -0500

>> > For one particular fontification in socket.c, the "safe position" is 500
>> > bytes back from the starting point, so jit-lock is pushed back these 500
>> > bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
>> > new start position set back 500 bytes, rinse, spin, repeat.
>> Why is "jit-lock pushed back"?
> Build Emacs revision #106728.  emacs -Q, then create the following C++
> buffer:

> #########################################################################
> 1 template <typename T>
> 2
> 3
> 4 void myfunc(T* p) {}
> #########################################################################

> This is fontified correctly.  Type a space on L2.  This is OK for half a
> second, then context fontification messes up L4.  The correct
> fontification can only be restored by a change to L4.

That explains why *font-lock* needs to be applied to "L1-L4", but now
why *jit-lock* needs to be affected.


        Stefan

Message #44 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Fri, 10 Feb 2012 11:28:57 +0000

Hi, Eli and Stefan.

On Wed, Feb 08, 2012 at 02:28:53PM -0500, Stefan Monnier wrote:
> >> > For one particular fontification in socket.c, the "safe position" is 500
> >> > bytes back from the starting point, so jit-lock is pushed back these 500
> >> > bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
> >> > new start position set back 500 bytes, rinse, spin, repeat.
> >> Why is "jit-lock pushed back"?
> > Build Emacs revision #106728.  emacs -Q, then create the following C++
> > buffer:

> > #########################################################################
> > 1 template <typename T>
> > 2
> > 3
> > 4 void myfunc(T* p) {}
> > #########################################################################

> > This is fontified correctly.  Type a space on L2.  This is OK for half a
> > second, then context fontification messes up L4.  The correct
> > fontification can only be restored by a change to L4.

> That explains why *font-lock* needs to be applied to "L1-L4", but now
> why *jit-lock* needs to be affected.

I was mistaken in my original diagnosis.  What is really happening is
that CC Mode is trying to go out of nested parens/brackets to find the
beginning of a declaration.

c-beginning-of-decl-1 (which _never_ goes back outside of
parens/brackets/braces) was given a limit (- (point) 500) which took it
to just after a (.  Then we went back out of the (.  Then did
c-beginning-of-decl-1 again, which moved _forward_ to the limit.  Repeat,
repeat, repeat ad infinitum.

The following patch should fix this.  Eli, would you please try it out
and let me know if there are still problems with it.


*** orig/cc-mode.el	2012-02-10 10:55:54.000000000 +0000
--- cc-mode.el	2012-02-10 11:27:56.000000000 +0000
***************
*** 1140,1146 ****
      (goto-char (c-point 'bol new-pos))
      (when lit-limits			; Comment or string.
        (goto-char (car lit-limits)))
!     (setq bod-lim (max (- (point) 500) (point-min)))
  
      (while
  	;; Go to a less nested declaration each time round this loop.
--- 1140,1146 ----
      (goto-char (c-point 'bol new-pos))
      (when lit-limits			; Comment or string.
        (goto-char (car lit-limits)))
!     (setq bod-lim (c-determine-limit 500))
  
      (while
  	;; Go to a less nested declaration each time round this loop.
***************
*** 1158,1168 ****
  	 ;; Try and go out a level to search again.
  	 (progn
  	   (c-backward-syntactic-ws bod-lim)
! 	   (or (memq (char-before) '(?\( ?\[))
! 	       (and (eq (char-before) ?\<)
! 		    (eq (c-get-char-property
! 			 (1- (point)) 'syntax-table)
! 			c-<-as-paren-syntax))))
  	 (not (bobp)))
        (backward-char))
      new-pos))				; back over (, [, <.
--- 1158,1169 ----
  	 ;; Try and go out a level to search again.
  	 (progn
  	   (c-backward-syntactic-ws bod-lim)
! 	   (and (> (point) bod-lim)
! 		(or (memq (char-before) '(?\( ?\[))
! 		    (and (eq (char-before) ?\<)
! 			 (eq (c-get-char-property
! 			      (1- (point)) 'syntax-table)
! 			     c-<-as-paren-syntax)))))
  	 (not (bobp)))
        (backward-char))
      new-pos))				; back over (, [, <.



>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #47 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10664 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Sun, 12 Feb 2012 22:57:22 +0200

> Date: Fri, 10 Feb 2012 11:28:57 +0000
> Cc: 10664 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> The following patch should fix this.  Eli, would you please try it out
> and let me know if there are still problems with it.

It seems to have cured the problem.  At least I cannot reproduce it
anymore in two C files where it happened before.

Thanks!

Message #50 received at 10664 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alan Mackenzie <acm <at> muc.de>, 10664 <at> debbugs.gnu.org
Subject: Re: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 14 Feb 2012 13:42:04 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 10 Feb 2012 11:28:57 +0000
>> Cc: 10664 <at> debbugs.gnu.org
>> From: Alan Mackenzie <acm <at> muc.de>
>> 
>> The following patch should fix this.  Eli, would you please try it out
>> and let me know if there are still problems with it.
>
> It seems to have cured the problem.  At least I cannot reproduce it
> anymore in two C files where it happened before.
>
> Thanks!

Alan's committed this (revno 107269); closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.