From: Michael Heerdegen <michael_heerdegen@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Christopher Schmidt <christopher@ristopher.com>, 12196@debbugs.gnu.org
Subject: bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs
Date: Sun, 26 Aug 2012 17:58:45 +0200 [thread overview]
Message-ID: <877gsl7ih6.fsf@web.de> (raw)
In-Reply-To: <83ehmwh0pn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Aug 2012 16:35:32 +0300")
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.
prev parent reply other threads:[~2012-08-26 15:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 4:54 bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs Michael Heerdegen
2012-08-15 16:36 ` Eli Zaretskii
2012-08-24 12:19 ` Michael Heerdegen
2012-08-24 13:35 ` Eli Zaretskii
2012-08-26 11:53 ` Christopher Schmidt
2012-08-31 8:50 ` Eli Zaretskii
2012-09-10 10:28 ` Christopher Schmidt
2012-09-10 11:10 ` Eli Zaretskii
2012-09-10 13:19 ` Christopher Schmidt
2012-09-10 17:10 ` Eli Zaretskii
2012-09-10 17:31 ` Christopher Schmidt
2012-09-10 18:43 ` Eli Zaretskii
2012-09-17 17:17 ` Christopher Schmidt
2012-09-17 18:38 ` Eli Zaretskii
2012-09-17 18:53 ` Christopher Schmidt
2012-09-17 20:18 ` Eli Zaretskii
2012-09-18 7:25 ` Christopher Schmidt
2012-09-18 8:02 ` Eli Zaretskii
2012-08-26 15:58 ` Michael Heerdegen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gsl7ih6.fsf@web.de \
--to=michael_heerdegen@web.de \
--cc=12196@debbugs.gnu.org \
--cc=christopher@ristopher.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.