From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: xdisp.c problem? Date: Thu, 30 Jan 2003 12:51:03 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301300351.MAA18471@etlken.m17n.org> References: <20030129.153321.35784511.Takaaki.Ota@am.sony.com> <200301300000.JAA18264@etlken.m17n.org> <20030129.174125.01368882.Takaaki.Ota@am.sony.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1043898653 10637 80.91.224.249 (30 Jan 2003 03:50:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 30 Jan 2003 03:50:53 +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 18e5iy-0002lO-00 for ; Thu, 30 Jan 2003 04:50:48 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18e5oS-0005r9-00 for ; Thu, 30 Jan 2003 04:56:28 +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 18e5jt-0004RL-07 for emacs-devel@quimby.gnus.org; Wed, 29 Jan 2003 22:51:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18e5ja-0004RD-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 22:51:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18e5jZ-0004Ph-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 22:51:26 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18e5jY-0004Gu-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 22:51:24 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0U3p4k05821; Thu, 30 Jan 2003 12:51:04 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0U3p3R07190; Thu, 30 Jan 2003 12:51:03 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id MAA18471; Thu, 30 Jan 2003 12:51:03 +0900 (JST) Original-To: Takaaki.Ota@am.sony.com In-reply-to: <20030129.174125.01368882.Takaaki.Ota@am.sony.com> (message from Tak Ota on Wed, 29 Jan 2003 17:41:25 -0800 (PST)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:11211 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11211 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. It's not likely that the modified function set_cursor_from_row itself has an infinite loop, but it may set cursor position to where the other display engine code don't expect. --- Ken'ichi HANDA handa@m17n.org