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#18528: 24.3.93; Crash during restoration of frameset from desktop Date: Mon, 22 Sep 2014 21:13:53 +0300 Message-ID: <83bnq7y13y.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1411411281 2571 80.91.229.3 (22 Sep 2014 18:41:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2014 18:41:21 +0000 (UTC) Cc: 18528@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 22 20:41:14 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XW8Xw-0000kV-KQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Sep 2014 20:41:12 +0200 Original-Received: from localhost ([::1]:48299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW8Xw-0007C0-7L for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Sep 2014 14:41:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW8Xk-00077N-Ny for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:41:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW8Xd-0002z8-Ne for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:41:00 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW8Xd-0002yQ-K7 for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:40:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XW88c-0007lt-9t for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Sep 2014 18:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18528 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.141140967629821 (code B ref -1); Mon, 22 Sep 2014 18:15:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 22 Sep 2014 18:14:36 +0000 Original-Received: from localhost ([127.0.0.1]:49116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW88B-0007kt-EM for submit@debbugs.gnu.org; Mon, 22 Sep 2014 14:14:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53790) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW888-0007ki-JX for submit@debbugs.gnu.org; Mon, 22 Sep 2014 14:14:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW881-0003db-IG for submit@debbugs.gnu.org; Mon, 22 Sep 2014 14:14:32 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:60629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW881-0003bw-Eo for submit@debbugs.gnu.org; Mon, 22 Sep 2014 14:14:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW87q-00050D-H6 for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:14:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW87j-0003XV-VS for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:14:14 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:33980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW87j-0003WZ-OI for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 14:14:07 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NCB00E00E64IM00@a-mtaout23.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 21:14:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCB00EZ3ENCFG70@a-mtaout23.012.net.il>; Mon, 22 Sep 2014 21:14:01 +0300 (IDT) In-reply-to: <54205FCF.4050503@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:93642 Archived-At: > Date: Mon, 22 Sep 2014 19:43:43 +0200 > From: martin rudalics > > > (gdb) p f->text_cols > > $6 = -3 <<<<<<<<<<<<<<<<<<< > > What is the value of f->text_width here? 18, as expected (minimum width is 2 columns). > > (We also don't check errors returned by > > GetClientRect.) > > Should we? I certainly think so. If GetClientRect fails, how does it make sense to use what we find in the rectangle data structure we passed to it? The values there are just garbage. > I wonder already why > > if (f && !FRAME_ICONIFIED_P (f) && msg.msg.wParam != SIZE_MINIMIZED) > > in w32_read_socket didn't catch this. I have no idea, perhaps because we already made the frame visible, but the window manager didn't yet have time to actually do so. The fact is we do get all-zero rectangle, I've seen that in the debugger. > > + if (GetClientRect (msg.msg.hwnd, &rect) > > + /* GetClientRect evidently returns (0, 0, 0, 0) if > > + called on a minimized frame. Such "dimensions" > > + aren't useful anyway. */ > > + && !(rect.bottom == 0 > > + && rect.top == 0 > > + && rect.left == 0 > > + && rect.right == 0)) > > It certainly can't harm to do that but I doubt whether it's worth to > include a similar change for the other platforms. I don't suggest such changes for other platforms, only for w32. > > + /* Recompute the dimensions in character units, since > > + check_frame_size might have changed the pixel dimensions. */ > > + /* Consider rounding here: Currently, the root window can be > > + larger than the frame in terms of columns/lines. */ > > + new_cols = new_text_width / FRAME_COLUMN_WIDTH (f); > > + new_lines = new_text_height / FRAME_LINE_HEIGHT (f); > > This part should fix the problem for all platforms. > > Please check it in but please also make sure that only the changes in > adjust_decode_mode_spec_buffer and maybe those of w32_read_socket get > propagated to the trunk. The rest of the changes won't get propagated because the relevant code in change_frame_size_1 is gone on the trunk. > Did you verify that the trunk handles your .emacs.desktop correctly? No, I didn't have a trunk binary on that machine. But if the validation of the frame dimensions on the tyrunk doesn't suffer from this problem, the bug shouldn't happen. Btw, the problem has nothing to do with my .emacs.desktop: the call to w32_read_socket was from the loop where we wait for the frame to become visible. It can happen at any time with any desktop file that re-creates more than one frame.