From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#10035: Crash in check_x_frame in w32fns.c Date: Mon, 14 Nov 2011 05:55:26 +0200 Message-ID: <83zkfze4sx.fsf@gnu.org> References: <4EBFE25E.3010101@gmail.com> <838vnkeybb.fsf@gnu.org> <4EC022EB.2030508@gmail.com> <8339drg4dy.fsf@gnu.org> <4EC02EC2.8060703@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321243119 19941 80.91.229.12 (14 Nov 2011 03:58:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2011 03:58:39 +0000 (UTC) Cc: 10035@debbugs.gnu.org To: Christoph Scholtes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 04:58:35 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RPngp-0005Ps-Eq for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2011 04:58:35 +0100 Original-Received: from localhost ([::1]:50642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPngp-0005e1-4y for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Nov 2011 22:58:35 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:58967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPngn-0005dw-5T for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2011 22:58:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPngl-00052V-S6 for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2011 22:58:33 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPngl-00052O-PL for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2011 22:58:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RPnhG-0003Ub-P9 for bug-gnu-emacs@gnu.org; Sun, 13 Nov 2011 22:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Nov 2011 03:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10035 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10035-submit@debbugs.gnu.org id=B10035.132124309213369 (code B ref 10035); Mon, 14 Nov 2011 03:59:02 +0000 Original-Received: (at 10035) by debbugs.gnu.org; 14 Nov 2011 03:58:12 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPngS-0003TZ-Mg for submit@debbugs.gnu.org; Sun, 13 Nov 2011 22:58:12 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPngP-0003TJ-8j for 10035@debbugs.gnu.org; Sun, 13 Nov 2011 22:58:10 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUM00I00TGR8Y00@a-mtaout22.012.net.il> for 10035@debbugs.gnu.org; Mon, 14 Nov 2011 05:57:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.184.15]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUM00HWXTNKSOC0@a-mtaout22.012.net.il>; Mon, 14 Nov 2011 05:57:21 +0200 (IST) In-reply-to: <4EC02EC2.8060703@gmail.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 13 Nov 2011 22:59:02 -0500 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:53883 Archived-At: > Date: Sun, 13 Nov 2011 13:55:30 -0700 > From: Christoph Scholtes > CC: 10035@debbugs.gnu.org > > On 11/13/2011 1:21 PM, Eli Zaretskii wrote: > > > Sorry, I meant to type this in frame #2, where a and be are arguments > > of the function row_equal_p: > > > >> #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > >> at dispnew.c:398 > > (gdb) p a->enabled_p > $2 = 1 > (gdb) p b->enabled_p > $3 = 1 Good. Now let's see what are these two glyph rows: (gdb) prowx a (gdb) prowx b (gdb) pgrowx a (gdb) pgrowx b The last two commands will display all the display elements (characters, references to images and display strings, etc.) in each glyph row. Assuming it is not a total garbage, please try to describe what happened on the screen around these glyph rows (== screen lines). A bit of a background: scrolling_window, the function that called row_equal_p, is comparing the previous and the new contents of a window, trying to figure out which screen lines need to be redrawn and which can be reused from the previous redisplay cycle. row_equal_p is the comparison function. So one of the glyph rows should be from the window before some update, the other glyph row is from the new contents of the window. They could be identical or they could be different. > > #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > > at dispnew.c:398 > > #3 0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0) > > at dispnew.c:398 > > #4 0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398 > > #5 0x010f27fe in update_window_tree (w=0x10d96000, force_p=1) > > at dispnew.c:398 > > #6 0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1) > > at dispnew.c:398 > > #7 0x010f254d in update_frame (f=0x3a24e00, force_p=1, inhibit_hairy_id_p=0) > > at dispnew.c:398 > > > > We are obviously very smart if we succeeded to squeeze all these > > functions into a single source line ;-) > > Interesting. I didn't notice that. > > > What version of GCC is that? > > tdm-gcc 4.6.1 If this is an unoptimized build, this shouldn't happen, and perhaps it's a compiler bug. Or maybe GCC 4.6 does some optimizations even with -O0.