From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tak Ota Newsgroups: gmane.emacs.devel Subject: Re: xdisp.c problem? Date: Thu, 30 Jan 2003 15:56:20 -0800 (PST) Organization: Sony Electronics Inc. Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030130.155620.107709347.Takaaki.Ota@am.sony.com> References: <20030129.174125.01368882.Takaaki.Ota@am.sony.com> <200301300351.MAA18471@etlken.m17n.org> <20030130.131322.01368777.Takaaki.Ota@am.sony.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1043970965 5334 80.91.224.249 (30 Jan 2003 23:56:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 30 Jan 2003 23:56:05 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18eOXM-0001Ne-00 for ; Fri, 31 Jan 2003 00:56:04 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18eOdE-0000UT-00 for ; Fri, 31 Jan 2003 01:02:08 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18eOYv-0002Wo-02 for emacs-devel@quimby.gnus.org; Thu, 30 Jan 2003 18:57:41 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18eOYS-0002Re-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 18:57:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18eOYQ-0002PR-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 18:57:11 -0500 Original-Received: from mail6.fw-sj.sony.com ([160.33.82.73]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18eOXg-0001yC-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 18:56:24 -0500 Original-Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail6.fw-sj.sony.com (8.8.8/8.8.8) with ESMTP id XAA10048; Thu, 30 Jan 2003 23:56:21 GMT Original-Received: by mail2.sjc.in.sel.sony.com id XAA01033; Thu, 30 Jan 2003 23:56:21 GMT Original-To: handa@m17n.org In-Reply-To: <20030130.131322.01368777.Takaaki.Ota@am.sony.com> X-Telephone: +1-858-942-3239 X-Fax------: +1-858-942-9142 X-SnailMail: 16450 West Bernardo Drive MZ7205, San Diego, CA 92127-1804 X-Mailer: Mew-3.1.52 on Emacs-21.3.50.1 (i386-msvc-nt5.0.2195) of 2003-01-30 Original-cc: gerd.moellmann@t-online.de X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11241 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11241 Thu, 30 Jan 2003 13:13:22 -0800 (PST): Tak Ota wrote: > Thu, 30 Jan 2003 12:51:03 +0900 (JST): Kenichi Handa wrote: > > > In article <20030129.174125.01368882.Takaaki.Ota@am.sony.com>, Tak Ota writes: > > >> > 2003-01-29 Kenichi Handa > > >> > * xdisp.c (set_cursor_from_row): Pay attention to string display > > >> > properties. > > >> > > >> > This change causes emacs to get hung when I try to view a message of > > >> > the following type. Switching back to the old xdisp.c eliminates the > > >> > problem. > > >> > > >> > Content-Type: text/html; charset="euc-kr" > > >> > > >> Could you show me exactly what to do to reproduce that bug? > > > > > I tried to isolate the case from the entire circumstance, which is > > > using Mew package to view email messages. I was not successful. It > > > happens only when I try to view certain messages. C-g does not break > > > emacs once it gets trapped in this situation. There is one more fact > > > I have gained by tracing elisp execution. The last lisp function > > > called is `overlay-put' and the emacs stops responding after that. I > > > used C debugger to follow the trace from entry to `overlay-put' but > > > could not conclusion anything meaningful. > > > > Please check if Emacs is in an infinite loop or not, and if > > it's in an infinite loop, find in which part of code it's > > executing. > > Yes, Emacs is looping infinitely. It is spinning busily inside > command_loop_2 which calls internal_condition_case which calls > command_loop_1 which calls read_key_sequence. Somewhere down in > read_key_sequence is thrown an exception. The longjump lands back in > setjmp in the internal_condition_case which returns to > command_loop_2. This repeats forever. > > I tried to find what exception it is and from where in the downstream > of read_key_sequence it is thrown, then I ran out of my time for now. > I'll continue the pursuit later. Here is the complete trace to where unwind_to_catch brings us back to internal_condition_case and the descending starts all over again. The function set_cursor_from_row is in the trace. It was not a simple loop but continuous signal generation caused by the change to internal_condition_case. Since I'm not familiar with your change I'll simply keep the debugger as is for a while. Let me know if you want to examine values of specific variables. -Tak unwind_to_catch() line 1172 Fsignal(int 0x112b125c, int 0x519a46dc) line 1547 + 12 bytes args_out_of_range(int 0x00000000, int 0x00000000) line 140 + 35 bytes validate_interval_range(int 0x41942000, int * 0x0082f024, int * 0x0082f024, int 0x00000000) line 151 + 8 bytes Ftext_properties_at(int 0x00000000, int 0x41942000) line 585 + 16 bytes get_char_property_and_overlay(int 0x00000000, int 0x112d38ac, int 0x0082f030, int * 0x00000000) line 688 + 12 bytes Fnext_single_char_property_change(int 0x00000000, int 0x112d38ac, int 0x11297404, int 0x000006f5) line 802 set_cursor_from_row(window * 0x019f9400, glyph_row * 0x00000000, glyph_matrix * 0x01a85000, int 0x00000000, int 0x00000000, int 0x00000000, int 0x00000000) line 9527 + 24 bytes display_line(it * 0x01b0cc3c) line 13577 + 22 bytes try_window(int 0x419f9400, text_pos {...}) line 10978 + 12 bytes redisplay_window(int 0x419f9400, int 0x00000000) line 10617 + 10 bytes redisplay_window_0(int 0x419f9400) line 9437 + 10 bytes internal_condition_case_1(int (void)* 0x01046997 redisplay_window_0(int), int 0x419f9400, int 0x512c4654, int (void)* 0x01046980 redisplay_window_error(void)) line 1392 + 53 bytes redisplay_windows(int 0x4154a400) line 9418 + 29 bytes redisplay_windows(int 0x419f9000) line 9408 + 6 bytes redisplay_internal(int 0x00000000) line 9007 + 8 bytes redisplay() line 8433 + 7 bytes read_char(int 0x00000001, int 0x00000003, int * 0x0082fc9c, int 0x11297404, int * 0x0082fcd4) line 2430 read_key_sequence(int * 0x0082fd7c, int 0x0000001e, int 0x11297404, int 0x00000000, int 0x00000001, int 0x00000001) line 8533 + 36 bytes command_loop_1() line 1475 + 32 bytes internal_condition_case(int (void)* 0x0100e1da command_loop_1(void), int 0x112b1214, int (void)* 0x0100de6e cmd_error(void)) line 1352 command_loop_2() line 1270 + 21 bytes internal_catch(int 0x112a67c4, int (void)* 0x0100e0e2 command_loop_2(void), int 0x11297404) line 1112 + 6 bytes command_loop() line 1254 recursive_edit_1() line 969 + 5 bytes Frecursive_edit() line 1026 main() line 1659 + 5 bytes EMACS! mainCRTStartup + 180 bytes KERNEL32! 77ea847c()