From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alex Schroeder Newsgroups: gmane.emacs.devel Subject: Re: emacs hangs when loading image Date: Mon, 27 Dec 2004 02:20:39 +0100 Message-ID: <87brcg1qqg.fsf@confusibombus.emacswiki.org> References: <87zn02djst.fsf@confusibombus.emacswiki.org> <41CE8018.4030704@math.ku.dk> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1104110760 21377 80.91.229.6 (27 Dec 2004 01:26:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Dec 2004 01:26:00 +0000 (UTC) Cc: emacs-devel@gnu.org, "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 27 02:25:52 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cijdv-0003Lv-00 for ; Mon, 27 Dec 2004 02:25:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cijoh-0005Tl-QM for ged-emacs-devel@m.gmane.org; Sun, 26 Dec 2004 20:36:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cijny-0005NA-PQ for emacs-devel@gnu.org; Sun, 26 Dec 2004 20:36:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cijnt-0005Jl-SE for emacs-devel@gnu.org; Sun, 26 Dec 2004 20:36:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cijnt-0005Hn-70 for emacs-devel@gnu.org; Sun, 26 Dec 2004 20:36:09 -0500 Original-Received: from [62.2.95.247] (helo=smtp.hispeed.ch) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CijaQ-000268-HL for emacs-devel@gnu.org; Sun, 26 Dec 2004 20:22:14 -0500 Original-Received: from confusibombus.emacswiki.org.emacswiki.org (80-218-6-247.dclient.hispeed.ch [80.218.6.247]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id iBR1M7PR008961; Mon, 27 Dec 2004 02:22:08 +0100 Original-To: Lars Hansen Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAACkElEQVR42s1a0bLsIAgzjv// y7kPd9pVKxKVdk6fzux2C4EAwR6QZBpcQEopIf3Fq3a52Lfh0Mjjk99zcWYBwA2ihEen9jVxfAf/ u0+Y2HQwNoVw4Dx34trRV6NSjiLPmfPt77jwiBxB/3PnZ3B2AGxzHnGu0wcBwAIAyQwZGvQhiFcy YLOFQcSB/MS82n3ec37vykNqRFTX9rVWR2U5+pZNIggll0CUOQN9BDdm1LfBmcZxIEqjL6r2JU/D galaB7Zg4jlY2ulnIx9OR4iMRl38CAFyKaA8jAxE7lNn650VKMULZ/54crqn0YQCJGQliebXkFIK hwqmGm28cgsSjz/hzRCMneQEwMjVoH3gWTtMPgIslJUV5uIluvUEkyzU+gUGQO62e9NuSdZCzNOM fDPC87iCqfE9gHinsIrSL16TPBfrYIeHzqKU90a50jCh54EcrgAUFo5ibzvebgr/I66USQ0CspQp IVSoBQK3WswDDIndIraHxoglqOjM1d044PQvu1NY0EHtqQR/XwJ+PeCs0x2dSlApZVw4MPER23PD 7JekoHxrqTRod/2Gx5nhx5dfAJhqPt7tDMIZxNN/7lOIaparPn7ZQ88drlORC2eLWXowxIq4gHTh VN1BSmsHoxYAbPWDTuGQuuecS+aYQUYpfr0YqPQOuuUk5tApK077+2xfOYP+XyWEIwPcE49lvT9N y2+wU2KylGGp4yxlALcm6fSlmgk62yfSsfNunDl5d6W91MBUoZw679YAJoMMkhijuXdFOL+khaL2 s+g3zy4APQuQvSc/BNAYnkl6E8ivYtEHJXa1dihE3zgnKMdNgN8DiIwgA17NykUMvFDQ+LALvXXI BuBLAHv/DvBmc/0HzR03PqXmLcQAAAAASUVORK5CYII= In-Reply-To: <41CE8018.4030704@math.ku.dk> (Lars Hansen's message of "Sun, 26 Dec 2004 10:10:48 +0100") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31426 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31426 Lars Hansen writes: > In the thread "Emacs loops on large images" from the start of december I > reported that Emacs often loops when trying to display images larger > than the window. Maybe the problem you have seen is the same. I don't think so. It has something to do with processes. Notice: #5 0x08175641 in Faccept_process_output (process=162478740, timeout=0, timeout_msecs=137362409, just_this_one=137362409) at process.c:3778 And today, while I was working a lot with eshell and CVS, I got another hang... This time I find read_process_output_call on the stack... Weird. When I continued today's crash, waited a while, and interrupted it again, I got a huge stack of mark_object stuff, so I think that's something else... If only I know more about debugging Emacs. #4758 0x08131a51 in mark_object (arg=145) at alloc.c:5376 #4759 0x081314d0 in mark_object (arg=145) at alloc.c:5265 #4760 0x08131a51 in mark_object (arg=145) at alloc.c:5376 #4761 0x081314d0 in mark_object (arg=145) at alloc.c:5265 #4762 0x081317df in mark_object (arg=145) at alloc.c:5251 #4763 0x081314c6 in mark_object (arg=145) at alloc.c:5264 Alex. #0 0x08103e63 in adjust_markers_for_replace (from=106, from_byte=106, old_chars=8, old_bytes=106, new_chars=0, new_bytes=0) at insdel.c:493 #1 0x081056f0 in replace_range (from=106, to=114, new=157596715, prepare=1, inherit=0, markers=1) at insdel.c:1622 #2 0x08120a89 in Freplace_match (newtext=157596715, fixedcase=137362457, literal=137362457, string=137362409, subexp=106) at search.c:2613 #3 0x08145c71 in Feval (form=135967376) at eval.c:2143 #4 0x081433e0 in Fprogn (args=159729064) at eval.c:408 #5 0x08145d6f in Feval (form=137077404) at eval.c:2076 #6 0x08146649 in Ffuncall (nargs=2, args=0xbfffd124) at eval.c:2774 #7 0x0816f20d in Fbyte_code (bytestr=140620265, vector=1, maxdepth=-1073753824) at bytecode.c:686 #8 0x0814696d in funcall_lambda (fun=140422260, nargs=3, arg_vector=0xbfffd244) at eval.c:2961 #9 0x0814651c in Ffuncall (nargs=4, args=0xbfffd240) at eval.c:2831 #10 0x0816f20d in Fbyte_code (bytestr=140620817, vector=3, maxdepth=-1073753536) at bytecode.c:686 #11 0x0814696d in funcall_lambda (fun=139481596, nargs=3, arg_vector=0xbfffd374) at eval.c:2961 #12 0x0814651c in Ffuncall (nargs=4, args=0xbfffd370) at eval.c:2831 #13 0x0816f20d in Fbyte_code (bytestr=140620817, vector=3, maxdepth=-1073753232) at bytecode.c:686 #14 0x0814696d in funcall_lambda (fun=139255908, nargs=2, arg_vector=0xbfffd494) at eval.c:2961 #15 0x0814651c in Ffuncall (nargs=3, args=0xbfffd490) at eval.c:2831 #16 0x0816f20d in Fbyte_code (bytestr=137614249, vector=2, maxdepth=-1073752944) at bytecode.c:686 #17 0x0814696d in funcall_lambda (fun=139482020, nargs=3, arg_vector=0xbfffd654) at eval.c:2961 #18 0x0814651c in Ffuncall (nargs=4, args=0xbfffd650) at eval.c:2831 #19 0x0814620e in run_hook_list_with_args (funlist=148486861, nargs=4, args=0xbfffd650) at eval.c:2494 #20 0x081066f4 in signal_after_change (charpos=110, lendel=0, lenins=4095) at insdel.c:2270 #21 0x0810483a in insert_from_string_before_markers (string=149682691, pos=0, ---Type to continue, or q to quit--- pos_byte=0, length=4095, length_byte=106, inherit=159729064) at insdel.c:1087 #22 0x0813d072 in general_insert_function ( insert_func=0x8104410 , insert_from_string_func=0x81047d0 , inherit=0, nargs=1, args=0xbfffd794) at editfns.c:2073 #23 0x0813d1af in Finsert_before_markers (nargs=1, args=0xbfffd794) at editfns.c:2160 #24 0x08146701 in Ffuncall (nargs=2, args=0xbfffd790) at eval.c:2755 #25 0x0816f20d in Fbyte_code (bytestr=137436817, vector=1, maxdepth=-1073752176) at bytecode.c:686 #26 0x0814696d in funcall_lambda (fun=148549500, nargs=2, arg_vector=0xbfffd8b4) at eval.c:2961 #27 0x0814651c in Ffuncall (nargs=3, args=0xbfffd8b0) at eval.c:2831 #28 0x08145ed3 in Fapply (nargs=2, args=0xbfffd930) at eval.c:2279 #29 0x081462d5 in apply1 (fn=159902705, arg=159832925) at eval.c:2535 #30 0x08176b28 in read_process_output_call (fun_and_args=159832917) at process.c:4710 #31 0x08144b01 in internal_condition_case_1 (bfun=0x8176b10 , arg=159832917, handlers=137423409, hfun=0x8176b30 ) at eval.c:1425 #32 0x08176dc3 in read_process_output (proc=140565100, channel=4095) at process.c:4933 #33 0x081762e4 in wait_reading_process_output (time_limit=-1, microsecs=0, read_kbd=0, do_display=0, wait_for_cell=137362409, wait_proc=0x89a6128, just_wait_proc=0) at process.c:4550 #34 0x08175641 in Faccept_process_output (process=144335148, timeout=0, timeout_msecs=137362409, just_this_one=137362409) at process.c:3778 #35 0x08146649 in Ffuncall (nargs=2, args=0xbfffedd0) at eval.c:2774 #36 0x0816f20d in Fbyte_code (bytestr=138114633, vector=1, maxdepth=-1073746368) at bytecode.c:686 #37 0x0814696d in funcall_lambda (fun=143156660, nargs=0, arg_vector=0xbfffef74) at eval.c:2961 #38 0x0814651c in Ffuncall (nargs=1, args=0xbfffef70) at eval.c:2831 #39 0x0816f20d in Fbyte_code (bytestr=137420097, vector=0, maxdepth=-1073746064) at bytecode.c:686 #40 0x0814696d in funcall_lambda (fun=143936684, nargs=0, arg_vector=0xbffff10c) at eval.c:2961 #41 0x0814651c in Ffuncall (nargs=1, args=0xbffff108) at eval.c:2831 ---Type to continue, or q to quit--- #42 0x0814611c in run_hook_with_args (nargs=1, args=0xbffff108, cond=to_completion) at eval.c:2442 #43 0x08145fc5 in Frun_hooks (nargs=1, args=0xbffff1b4) at eval.c:2310 #44 0x08146701 in Ffuncall (nargs=2, args=0xbffff1b0) at eval.c:2755 #45 0x08146328 in call1 (fn=137447289, arg1=137415433) at eval.c:2568 #46 0x080e6397 in safe_run_hooks_1 (hook=137362457) at keyboard.c:2037 #47 0x081449ea in internal_condition_case (bfun=0x80e6380 , handlers=137362457, hfun=0x80e63a0 ) at eval.c:1384 #48 0x080e642b in safe_run_hooks (hook=137415433) at keyboard.c:2065 #49 0x080e4db4 in command_loop_1 () at keyboard.c:1804 #50 0x081449ea in internal_condition_case (bfun=0x80e4a10 , handlers=137423409, hfun=0x80e4500 ) at eval.c:1384 #51 0x080e4826 in command_loop_2 () at keyboard.c:1312 #52 0x0814452a in internal_catch (tag=106, func=0x80e4800 , arg=137362409) at eval.c:1144 #53 0x080e47d5 in command_loop () at keyboard.c:1291 #54 0x080e4240 in recursive_edit_1 () at keyboard.c:984 #55 0x080e438c in Frecursive_edit () at keyboard.c:1045 #56 0x080e29e6 in main (argc=1, argv=0xbffff914) at emacs.c:1760 -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fifth law: OOO Never accept more work than you can handle in one night of hacking.