From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs 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 Message-ID: <877gsl7ih6.fsf@web.de> References: <87has6ysxn.fsf@web.de> <834no4jeoa.fsf@gnu.org> <87ehmwscrt.fsf@web.de> <83ehmwh0pn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1345996650 22991 80.91.229.3 (26 Aug 2012 15:57:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2012 15:57:30 +0000 (UTC) Cc: Christopher Schmidt , 12196@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 26 17:57:30 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T5fDK-0006Z0-VQ for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Aug 2012 17:57:27 +0200 Original-Received: from localhost ([::1]:51384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T5fDJ-00088e-53 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Aug 2012 11:57:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T5fDF-00080L-9m for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2012 11:57:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T5fD9-0003Lw-6s for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2012 11:57:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T5fD9-0003Lo-2q for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2012 11:57:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T5fDu-0006h3-Cg for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2012 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Aug 2012 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12196 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12196-submit@debbugs.gnu.org id=B12196.134599664425678 (code B ref 12196); Sun, 26 Aug 2012 15:58:02 +0000 Original-Received: (at 12196) by debbugs.gnu.org; 26 Aug 2012 15:57:24 +0000 Original-Received: from localhost ([127.0.0.1]:50891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5fDH-0006g6-Be for submit@debbugs.gnu.org; Sun, 26 Aug 2012 11:57:23 -0400 Original-Received: from mout.web.de ([212.227.15.3]:51097) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5fDF-0006fz-9j for 12196@debbugs.gnu.org; Sun, 26 Aug 2012 11:57:22 -0400 Original-Received: from snow.dragon ([89.204.137.140]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M8zSL-1Sw4oB3QvF-00D0WS; Sun, 26 Aug 2012 17:56:29 +0200 In-Reply-To: <83ehmwh0pn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Aug 2012 16:35:32 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Provags-ID: V02:K0:4DlTHTUeAilUxPRD4ZrcAlOXIUWI66ryEVYWpdxhR47 cdj1Kx+0EBToEpal99spccaBN1GZ+fWBP6xVsdXpbS9xB7fkFF bo1eD8pXc5WlCdP/ezcv3C4/VUba9kid2SCFqN8PFZlARuFbdl lvnW2yRLNxa5mwx8hD0fy7rRRfhagopE9LFG2+tL6DxvfFFp2q 3HRJzWN5cmdfvtp/SuuRraTjwftE2Ow5vdlG6mHXfs= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63507 Archived-At: Eli Zaretskii 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 * 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=) 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 , handlers=138889274, hfun=hfun@entry=0x8140970 ) 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 , 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=, 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.