bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> Do you see a reference to bug#12196 in src/ChangeLog of that
> distribution?  If not, then my fix is not included.

Yes, I see it:

2012-08-15  Eli Zaretskii  <eliz@gnu.org>

	* region-cache.c (move_cache_gap): Update gap_len using the actual
	growth of the boundaries array.  Do not change cache_len.
	(Bug#12196)

> Does Emacs really freeze, or does it just do some prolonged operation?
> (And is your CPU really an i486?)  If you wait for a long time, does
> Emacs eventually recover and become responsive again?

No, it really freezes.  I can wait ten minutes and emacs doesn't become
responsive again.

uname says that my CPU is an i686.  To be honest, I don't know much
about hardware.  But I used the emacs-snapshot binaries nearly everyday
for many months without seeing any freezes besides these.

> If Emacs really freezes, attach a debugger to it when it does, type
> "bt" at the debugger's prompt, and post here everything the debugger
> displays in response.

Here is a backtrace:

#0  0x08167976 in buf_charpos_to_bytepos (b=0x8e72420, charpos=charpos@entry=32027) at marker.c:168
#1  0x08185005 in scan_buffer (target=target@entry=10, start=32027, start@entry=27007, end=32089, 
    end@entry=0, count=count@entry=1, shortage=shortage@entry=0xbf9e418c, 
    allow_quit=allow_quit@entry=1) at search.c:677
#2  0x08185777 in find_before_next_newline (from=27007, to=to@entry=0, cnt=1) at search.c:945
#3  0x081a9b73 in Fline_end_position (n=<optimized out>) at editfns.c:808
#4  0x081afc83 in Ffuncall (nargs=1, args=0xbf9e4274) at eval.c:2837
#5  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=202, maxdepth=149365792, 
    args_template=138855706, nargs=0, args=0x0) at bytecode.c:898
#6  0x081af7e7 in funcall_lambda (fun=137048477, nargs=nargs@entry=4, 
    arg_vector=arg_vector@entry=0xbf9e4438) at eval.c:3069
#7  0x081afaca in Ffuncall (nargs=5, args=0xbf9e4434) at eval.c:2898
#8  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146912, maxdepth=149365792, 
    args_template=5128, nargs=5, args=0xbf9e45d0) at bytecode.c:898
#9  0x081af6d3 in funcall_lambda (fun=140693133, nargs=nargs@entry=5, 
    arg_vector=arg_vector@entry=0xbf9e45d0) at eval.c:3003
#10 0x081afaca in Ffuncall (nargs=6, args=0xbf9e45cc) at eval.c:2898
#11 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, maxdepth=149365792, args_template=0, 
    nargs=0, args=0xbf9e475c) at bytecode.c:898
#12 0x081af6d3 in funcall_lambda (fun=141473149, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0xbf9e475c) at eval.c:3003
#13 0x081afaca in Ffuncall (nargs=1, args=0xbf9e4758) at eval.c:2898
#14 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146088, maxdepth=149365792, 
    args_template=0, nargs=0, args=0xbf9e48f8) at bytecode.c:898
#15 0x081af6d3 in funcall_lambda (fun=148465485, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0xbf9e48f8) at eval.c:3003
#16 0x081afaca in Ffuncall (nargs=1, args=0xbf9e48f4) at eval.c:2898
#17 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145676, maxdepth=149365792, 
    args_template=3076, nargs=2, args=0xbf9e4a98) at bytecode.c:898
#18 0x081af6d3 in funcall_lambda (fun=140201581, nargs=nargs@entry=2, 
    arg_vector=arg_vector@entry=0xbf9e4a98) at eval.c:3003
#19 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4a94) at eval.c:2898
#20 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145276, maxdepth=149365792, 
    args_template=2052, nargs=2, args=0xbf9e4c24) at bytecode.c:898
#21 0x081af6d3 in funcall_lambda (fun=141836477, nargs=nargs@entry=2, 
    arg_vector=arg_vector@entry=0xbf9e4c24) at eval.c:3003
#22 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4c20) at eval.c:2898
#23 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, maxdepth=149365792, args_template=2052, 
    nargs=2, args=0xbf9e4d94) at bytecode.c:898
#24 0x081af6d3 in funcall_lambda (fun=141773429, nargs=nargs@entry=2, 
    arg_vector=arg_vector@entry=0xbf9e4d94) at eval.c:3003
#25 0x081afaca in Ffuncall (nargs=nargs@entry=3, args=args@entry=0xbf9e4d90) at eval.c:2898
#26 0x081b0b33 in Fapply (nargs=nargs@entry=2, args=args@entry=0xbf9e4e08) at eval.c:2343
#27 0x081b007f in apply1 (fn=fn@entry=140543522, arg=arg@entry=140712190) at eval.c:2581
#28 0x081abecd in Fcall_interactively (function=140543522, record_flag=138855706, keys=138864797)
    at callint.c:378
#29 0x081afc62 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0xbf9e4f30) at eval.c:2844
#30 0x081aff27 in call3 (fn=138934218, arg1=140543522, arg2=138855706, arg3=138855706) at eval.c:2638
#31 0x0813e6f5 in Fcommand_execute (cmd=138934218, record_flag=140543522, keys=138855706, 
    special=138855706) at keyboard.c:10375
#32 0x0814ac63 in command_loop_1 () at keyboard.c:1639
#33 0x081ae230 in internal_condition_case (bfun=bfun@entry=0x814a930 <command_loop_1>, 
    handlers=138889274, hfun=hfun@entry=0x8140970 <cmd_error>) at eval.c:1322
#34 0x0813f745 in command_loop_2 (ignore=ignore@entry=138855706) at keyboard.c:1204
#35 0x081ae15b in internal_catch (tag=138887250, func=func@entry=0x813f720 <command_loop_2>, 
    arg=138855706) at eval.c:1079
#36 0x081404aa in command_loop () at keyboard.c:1183
#37 recursive_edit_1 () at keyboard.c:804
#38 0x0814079a in Frecursive_edit () at keyboard.c:868
#39 0x0805acb0 in main (argc=<optimized out>, argv=0xbf9e5644) at emacs.c:1662

> Then try to follow the advice in etc/DEBUG,
> under "If the symptom of the bug is that Emacs fails to respond", to
> establish which Emacs function, if any, is looping.

Since Christopher can also reproduce this problem, and since he surely
is a greater help here, I would prefer if you could work with him.


Thanks,

Michael.