* emacs hangs when loading image @ 2004-12-25 23:45 Alex Schroeder 2004-12-26 9:10 ` Lars Hansen 0 siblings, 1 reply; 10+ messages in thread From: Alex Schroeder @ 2004-12-25 23:45 UTC (permalink / raw) I remember some talk on emacs-devel about moving bug reports from the pretest list to emacs-devel. So I'm doing that. This is Emacs from CVS compiled a few days ago. In this session I was repeatedly opening a small number of files from dired with auto-image-file-mode enabled. When I hit RET on one of them, Emacs hangs. I attach GDB and hit bt. Looks like Emacs is waiting for something that isn't coming. Alex. #0 0x403d3812 in select () from /lib/libc.so.6 #1 0x00000000 in ?? () #2 0x0000000c in ?? () #3 0x00000000 in ?? () #4 0x08176119 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=0, do_display=0, wait_for_cell=137362409, wait_proc=0x9af3a90, just_wait_proc=0) at process.c:4349 #5 0x08175641 in Faccept_process_output (process=162478740, timeout=0, timeout_msecs=137362409, just_this_one=137362409) at process.c:3778 #6 0x08146649 in Ffuncall (nargs=2, args=0xbfffedd0) at eval.c:2774 #7 0x0816f20d in Fbyte_code (bytestr=138114633, vector=1, maxdepth=-1073746368) at bytecode.c:686 #8 0x0814696d in funcall_lambda (fun=143098756, nargs=0, arg_vector=0xbfffef74) at eval.c:2961 #9 0x0814651c in Ffuncall (nargs=1, args=0xbfffef70) at eval.c:2831 #10 0x0816f20d in Fbyte_code (bytestr=137420097, vector=0, maxdepth=-1073746064) at bytecode.c:686 #11 0x0814696d in funcall_lambda (fun=143098140, nargs=0, arg_vector=0xbffff10c) at eval.c:2961 #12 0x0814651c in Ffuncall (nargs=1, args=0xbffff108) at eval.c:2831 #13 0x0814611c in run_hook_with_args (nargs=1, args=0xbffff108, cond=to_completion) at eval.c:2442 #14 0x08145fc5 in Frun_hooks (nargs=1, args=0xbffff1b4) at eval.c:2310 #15 0x08146701 in Ffuncall (nargs=2, args=0xbffff1b0) at eval.c:2755 #16 0x08146328 in call1 (fn=137447289, arg1=137415433) at eval.c:2568 #17 0x080e6397 in safe_run_hooks_1 (hook=137362457) at keyboard.c:2037 #18 0x081449ea in internal_condition_case (bfun=0x80e6380 <safe_run_hooks_1>, handlers=137362457, hfun=0x80e63a0 <safe_run_hooks_error>) at eval.c:1384 #19 0x080e642b in safe_run_hooks (hook=137415433) at keyboard.c:2065 #20 0x080e4db4 in command_loop_1 () at keyboard.c:1804 #21 0x081449ea in internal_condition_case (bfun=0x80e4a10 <command_loop_1>, handlers=137423409, hfun=0x80e4500 <cmd_error>) at eval.c:1384 #22 0x080e4826 in command_loop_2 () at keyboard.c:1312 #23 0x0814452a in internal_catch (tag=-514, func=0x80e4800 <command_loop_2>, arg=137362409) at eval.c:1144 #24 0x080e47d5 in command_loop () at keyboard.c:1291 #25 0x080e4240 in recursive_edit_1 () at keyboard.c:984 #26 0x080e438c in Frecursive_edit () at keyboard.c:1045 #27 0x080e29e6 in main (argc=1, argv=0xbffff914) at emacs.c:1760 In GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2004-12-19 on confusibombus Distributor `The X.Org Foundation', version 11.0.60700000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C 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: en_US.ISO8859-1 locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t erc-bbdb-mode: t erc-page-mode: t erc-services-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t erc-smiley-mode: t recentf-mode: t iswitchb-mode: t auto-image-file-mode: t file-name-shadow-mode: t display-time-mode: t auto-compression-mode: t show-paren-mode: t mouse-wheel-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t Recent input: C-c e C-c C-SPC C-c C-SPC C-c C-SPC C-c C-SPC C-x b # e m a c s <return> <down-mouse-2> <mouse-2> <help-echo> <help-echo> C-x b s c r <return> C-y <help-echo> <down-mouse-2> <mouse-2> <C-up> <C-up> <C-up> C-SPC <C-down> <C-down> C-w M-x r e p o r t - - <backspace> e m a c s <tab> <return> C-g M-x g n u s <return> <help-echo> M-x r e p o r t - e m a c s - b u g <return> Recent messages: nnml: Reading incoming mail from file... Loading byte-opt...done nnml: Reading incoming mail (no new mail)...done Opening nntp server on news.gnus.org...done Opening nnfolder server...done Opening nndoc server on /home/alex/mailer-daemon...done Opening nntp server on news.gmane.org...done Opening nntp server on news.hispeed.ch...done Checking new news...done Loading gnus-topic...done -- .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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-25 23:45 emacs hangs when loading image Alex Schroeder @ 2004-12-26 9:10 ` Lars Hansen 2004-12-27 1:20 ` Alex Schroeder 2004-12-27 4:09 ` Richard Stallman 0 siblings, 2 replies; 10+ messages in thread From: Lars Hansen @ 2004-12-26 9:10 UTC (permalink / raw) Cc: Kim F. Storm, emacs-devel Alex Schroeder wrote: > In this session I was repeatedly opening a small number of files from > dired with auto-image-file-mode enabled. When I hit RET on one of > them, Emacs hangs. I attach GDB and hit bt. Looks like Emacs is > waiting for something that isn't coming. 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. With gdb I found out that Emacs loops in the while loop in xdisp.c: back_to_previous_visible_line_start. It seems that the code searches for a completely visible line, but there is no such line because the image is larger than the window. I haven't had time to look further into the problem and I know nothing about xdisp.c. I am cc'ing Kim hoping for help. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-26 9:10 ` Lars Hansen @ 2004-12-27 1:20 ` Alex Schroeder 2004-12-27 18:06 ` Richard Stallman 2004-12-27 18:06 ` Richard Stallman 2004-12-27 4:09 ` Richard Stallman 1 sibling, 2 replies; 10+ messages in thread From: Alex Schroeder @ 2004-12-27 1:20 UTC (permalink / raw) Cc: emacs-devel, Kim F. Storm Lars Hansen <larsh@math.ku.dk> 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 <return> to continue, or q <return> 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_before_markers>, insert_from_string_func=0x81047d0 <insert_from_string_before_markers>, 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 <read_process_output_call>, arg=159832917, handlers=137423409, hfun=0x8176b30 <read_process_output_error_handler>) 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 <return> to continue, or q <return> 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 <safe_run_hooks_1>, handlers=137362457, hfun=0x80e63a0 <safe_run_hooks_error>) 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 <command_loop_1>, handlers=137423409, hfun=0x80e4500 <cmd_error>) at eval.c:1384 #51 0x080e4826 in command_loop_2 () at keyboard.c:1312 #52 0x0814452a in internal_catch (tag=106, func=0x80e4800 <command_loop_2>, 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-27 1:20 ` Alex Schroeder @ 2004-12-27 18:06 ` Richard Stallman 2004-12-27 18:06 ` Richard Stallman 1 sibling, 0 replies; 10+ messages in thread From: Richard Stallman @ 2004-12-27 18:06 UTC (permalink / raw) Cc: larsh, storm, emacs-devel 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. That could be normal, during GC. I suggest you find the frame for Fgarbage_collect and type `finish' in that frame; then you will see if GC finishes. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-27 1:20 ` Alex Schroeder 2004-12-27 18:06 ` Richard Stallman @ 2004-12-27 18:06 ` Richard Stallman 1 sibling, 0 replies; 10+ messages in thread From: Richard Stallman @ 2004-12-27 18:06 UTC (permalink / raw) Cc: larsh, storm, emacs-devel #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 The args to adjust_markers_for_replace look wrong. Specifically, it is really strange that old_bytes is 106. 8 characters are not likely to occupy 106 bytes. Could you look at the code in replace_range and see how it computed old_bytes? And in general check those values. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-26 9:10 ` Lars Hansen 2004-12-27 1:20 ` Alex Schroeder @ 2004-12-27 4:09 ` Richard Stallman 2004-12-27 9:28 ` Lars Hansen 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2004-12-27 4:09 UTC (permalink / raw) Cc: storm, emacs-devel, alex With gdb I found out that Emacs loops in the while loop in xdisp.c: back_to_previous_visible_line_start. It seems that the code searches for a completely visible line, but there is no such line because the image is larger than the window. I don't see anything in that function that tries to test the height of a line. However, I did see this if (handle_display_prop (&it2) == HANDLED_RETURN) visible_p = 0; which treats text containing certain kinds of `display' properties as if it were invisible. This seems to include images. I am not sure why it does that. It doesn't seem logical. We could try deleting those two lines. I don't know what it would break. Could you try deleting them and see if it fixes things? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-27 4:09 ` Richard Stallman @ 2004-12-27 9:28 ` Lars Hansen 2004-12-27 22:35 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Lars Hansen @ 2004-12-27 9:28 UTC (permalink / raw) Cc: storm, emacs-devel, alex > > >However, I did see this > > if (handle_display_prop (&it2) == HANDLED_RETURN) > visible_p = 0; > >which treats text containing certain kinds of `display' properties as >if it were invisible. This seems to include images. > >I am not sure why it does that. It doesn't seem logical. >We could try deleting those two lines. I don't know what >it would break. > >Could you try deleting them and see if it fixes things? > > > It does! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-27 9:28 ` Lars Hansen @ 2004-12-27 22:35 ` Richard Stallman 2004-12-28 8:27 ` Lars Hansen 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2004-12-27 22:35 UTC (permalink / raw) Cc: storm, emacs-devel, alex I will comment out those two lines, but I want to put in a reference to some precise and complete test case. Those lines were probably added for some reason, and the reason may not be obsolete. When someone finds a bug caused by the deletion, I want him to see a comment explaining *precisely* the case which led to the deletion. Can you put a precise test case (including the specific images to use) into a web page? Or find an image small enough in bytes that you can reasonably mail it to emacs-devel? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-27 22:35 ` Richard Stallman @ 2004-12-28 8:27 ` Lars Hansen 2004-12-28 20:57 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Lars Hansen @ 2004-12-28 8:27 UTC (permalink / raw) Cc: storm, emacs-devel, alex Richard Stallman wrote: >Can you put a precise test case (including the specific images to use) >into a web page? Or find an image small enough in bytes that you can >reasonably mail it to emacs-devel? > > I have been struggling to find a test case that works every time, but the same sequence of commands does not give the same result. However, the following test case works for me (i.e. makes Emacs loop) almost every time: Copy the two files xdisp.c and foo.jpg from http://www.math.ku.dk/~larsh/emacs/emacs-loops-on-large-images/ to some local directory, say ~/test. Then do $ cd ~/test $ emacs -Q C-x C-f xdisp.c M-x font-lock-mode M-x auto-image-mode C-x C-f foo.jpg This description is also placed in http://www.math.ku.dk/~larsh/emacs/emacs-loops-on-large-images/test-case.txt. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: emacs hangs when loading image 2004-12-28 8:27 ` Lars Hansen @ 2004-12-28 20:57 ` Richard Stallman 0 siblings, 0 replies; 10+ messages in thread From: Richard Stallman @ 2004-12-28 20:57 UTC (permalink / raw) Cc: emacs-devel, alex, storm Ok, I turned off those two lines. We'll see what other case breaks as a result. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-12-28 20:57 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-12-25 23:45 emacs hangs when loading image Alex Schroeder 2004-12-26 9:10 ` Lars Hansen 2004-12-27 1:20 ` Alex Schroeder 2004-12-27 18:06 ` Richard Stallman 2004-12-27 18:06 ` Richard Stallman 2004-12-27 4:09 ` Richard Stallman 2004-12-27 9:28 ` Lars Hansen 2004-12-27 22:35 ` Richard Stallman 2004-12-28 8:27 ` Lars Hansen 2004-12-28 20:57 ` Richard Stallman
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.