From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Sep 2014 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18528 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18528@debbugs.gnu.org Cc: martin rudalics X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.14113994388251 (code B ref -1); Mon, 22 Sep 2014 15:24:02 +0000 Received: (at submit) by debbugs.gnu.org; 22 Sep 2014 15:23:58 +0000 Received: from localhost ([127.0.0.1]:49017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW5T2-000290-JR for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59398) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW5Sz-00028r-Lf for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW5So-000545-QA for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5So-00053i-NO for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5Sc-00056Z-5V for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW5SU-000506-Gi for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:30 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:35387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5ST-0004yg-Vc for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:22 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NCB00J0066ANJ00@mtaout24.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 18:17:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCB00IJO6HKHB20@mtaout24.012.net.il>; Mon, 22 Sep 2014 18:17:44 +0300 (IDT) Date: Mon, 22 Sep 2014 18:23:07 +0300 From: Eli Zaretskii X-012-Sender: halo1@inter.net.il Message-id: <83egv3y90k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) Today I started Emacs 24.3.93, and it crashed near the end of restoring the last session from .emacs.desktop, when it was re-creating the frames recorded in that file. Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. _malloc_internal_nolock (size=size@entry=4294967285) at gmalloc.c:897 897 gmalloc.c: No such file or directory. (gdb) bt 10 #0 _malloc_internal_nolock (size=size@entry=4294967285) at gmalloc.c:897 #1 0x011eff12 in _realloc_internal_nolock (ptr=0x3e89600, size=4294967285) at gmalloc.c:1441 #2 0x01123f22 in xrealloc (block=0x3e89600, size=4294967285) at alloc.c:717 #3 0x0100a25e in adjust_decode_mode_spec_buffer (f=) at dispnew.c:2106 #4 adjust_frame_glyphs (f=f@entry=0x418ca80) at dispnew.c:1756 #5 0x0100abd0 in change_frame_size_1 (f=0x418ca80, new_width=, new_height=, pretend=pretend@entry=false, delay=delay@entry=false, safe=safe@entry=false, pixelwise=pixelwise@entry=true) at dispnew.c:5596 #6 0x0100cc89 in change_frame_size (pixelwise=true, safe=, delay=false, pretend=false, new_height=, new_width=, f=) at dispnew.c:5471 #7 do_pending_window_change (safe=safe@entry=false) at dispnew.c:5432 #8 0x0100e9e8 in Fset_frame_size (frame=frame@entry=104658605, width=2880, height=3740, pixelwise=65550402) at frame.c:2645 #9 0x010126ad in x_set_frame_parameters (f=f@entry=0x63cf6a8, alist=) at frame.c:3002 (More stack frames follow...) (gdb) frame 4 #4 adjust_frame_glyphs (f=f@entry=0x418ca80) at dispnew.c:1756 1756 in dispnew.c (gdb) p/x f $5 = 0x418ca80 (gdb) p f->text_cols $6 = -3 <<<<<<<<<<<<<<<<<<< As you can see, the text_cols member is negative. This is the immediate cause of the crash, because adjust_decode_mode_spec_buffer does this: static void adjust_decode_mode_spec_buffer (struct frame *f) { f->decode_mode_spec_buffer = xrealloc (f->decode_mode_spec_buffer, FRAME_MESSAGE_BUF_SIZE (f) + 1); } and FRAME_MESSAGE_BUF_SIZE is defined like this: #define FRAME_MESSAGE_BUF_SIZE(f) (((int) FRAME_COLS (f)) * 4) So we pass a negative value to xrealloc, which interprets it as a very large positive value, with predictable results. Some digging into this reveals the following: . The negative values come from w32term.c, around line 4770, where they are derived from the value returned by GetClientRect. Evidently, it sometimes returns a (0, 0, 0, 0) rectangle for the frame dimensions, from which we then subtract the dimensions of frame decorations, like scroll bar etc., and call change_frame_size. (We also don't check errors returned by GetClientRect.) . change_frame_size internally validates the requested dimensions, and doesn't allow them to become too small. But it does that on pixel dimensions, and if those are corrected, the character-unit dimensions are not recalculated to reflect those corrections. Below please find a patch that I intend to commit to the emacs-24 branch if no one objects. Martin, I'd appreciate your review, especially for the dispnew.c parts. TIA --- src/w32term.c~0 2014-05-24 23:48:43 +0300 +++ src/w32term.c 2014-09-21 17:48:00 +0300 @@ -4754,34 +4754,42 @@ w32_read_socket (struct terminal *termin RECT rect; int rows, columns, width, height, text_width, text_height; - GetClientRect (msg.msg.hwnd, &rect); - - height = rect.bottom - rect.top; - width = rect.right - rect.left; - text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, width); - text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, height); - rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, height); - columns = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, width); - - /* TODO: Clip size to the screen dimensions. */ - - /* Even if the number of character rows and columns has - not changed, the font size may have changed, so we need - to check the pixel dimensions as well. */ - - if (width != FRAME_PIXEL_WIDTH (f) - || height != FRAME_PIXEL_HEIGHT (f) - || text_width != FRAME_TEXT_WIDTH (f) - || text_height != FRAME_TEXT_HEIGHT (f)) + 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)) { - change_frame_size (f, text_width, text_height, 0, 1, 0, 1); - SET_FRAME_GARBAGED (f); - cancel_mouse_face (f); - /* Do we want to set these here ???? */ -/** FRAME_PIXEL_WIDTH (f) = width; **/ -/** FRAME_TEXT_WIDTH (f) = text_width; **/ -/** FRAME_PIXEL_HEIGHT (f) = height; **/ - f->win_gravity = NorthWestGravity; + height = rect.bottom - rect.top; + width = rect.right - rect.left; + text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, width); + text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, height); + rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, height); + columns = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, width); + + /* TODO: Clip size to the screen dimensions. */ + + /* Even if the number of character rows and columns + has not changed, the font size may have changed, + so we need to check the pixel dimensions as well. */ + + if (width != FRAME_PIXEL_WIDTH (f) + || height != FRAME_PIXEL_HEIGHT (f) + || text_width != FRAME_TEXT_WIDTH (f) + || text_height != FRAME_TEXT_HEIGHT (f)) + { + change_frame_size (f, text_width, text_height, 0, 1, 0, 1); + SET_FRAME_GARBAGED (f); + cancel_mouse_face (f); + /* Do we want to set these here ???? */ + /** FRAME_PIXEL_WIDTH (f) = width; **/ + /** FRAME_TEXT_WIDTH (f) = text_width; **/ + /** FRAME_PIXEL_HEIGHT (f) = height; **/ + f->win_gravity = NorthWestGravity; + } } } --- src/dispnew.c~1 2014-08-17 07:29:32 +0300 +++ src/dispnew.c 2014-09-22 17:40:15 +0300 @@ -2139,8 +2139,11 @@ adjust_frame_glyphs_for_window_redisplay static void adjust_decode_mode_spec_buffer (struct frame *f) { + ssize_t frame_message_buf_size = FRAME_MESSAGE_BUF_SIZE (f); + + eassert (frame_message_buf_size >= 0); f->decode_mode_spec_buffer = xrealloc (f->decode_mode_spec_buffer, - FRAME_MESSAGE_BUF_SIZE (f) + 1); + frame_message_buf_size + 1); } @@ -5540,10 +5543,6 @@ change_frame_size_1 (struct frame *f, in { new_text_width = (new_width == 0) ? FRAME_TEXT_WIDTH (f) : new_width; new_text_height = (new_height == 0) ? FRAME_TEXT_HEIGHT (f) : new_height; - /* 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); } else { @@ -5556,6 +5555,12 @@ change_frame_size_1 (struct frame *f, in /* Compute width of windows in F. */ /* Round up to the smallest acceptable size. */ check_frame_size (f, &new_text_width, &new_text_height, 1); + /* 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 is the width of the frame without vertical scroll bars and fringe columns. Do this after rounding - see discussion of In GNU Emacs 24.3.93.1 (i686-pc-mingw32) of 2014-08-15 on HOME-C4E4A596F7 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-Og -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e o p p o r t - e m Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 74217 7009) (symbols 32 17535 0) (miscs 32 33 127) (strings 16 10776 4344) (string-bytes 1 269654) (vectors 8 9550) (vector-slots 4 384749 6002) (floats 8 57 196) (intervals 28 237 95) (buffers 508 11)) From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Sep 2014 17:45:01 +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: To: eliz@gnu.org, 18528@debbugs.gnu.org X-Debbugs-Original-To: Eli Zaretskii , bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.141140787826961 (code B ref -1); Mon, 22 Sep 2014 17:45:01 +0000 Received: (at submit) by debbugs.gnu.org; 22 Sep 2014 17:44:38 +0000 Received: from localhost ([127.0.0.1]:49091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW7fB-00070n-BX for submit@debbugs.gnu.org; Mon, 22 Sep 2014 13:44:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45105) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW7f8-00070d-Ez for submit@debbugs.gnu.org; Mon, 22 Sep 2014 13:44:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW7ey-00033V-FL for submit@debbugs.gnu.org; Mon, 22 Sep 2014 13:44:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:53355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW7ey-00032L-Cq for submit@debbugs.gnu.org; Mon, 22 Sep 2014 13:44:24 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW7ek-000809-Pt for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 13:44:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW7ed-0002zg-A4 for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 13:44:10 -0400 Received: from mout.gmx.net ([212.227.15.15]:65215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW7eV-0002v8-5M; Mon, 22 Sep 2014 13:43:55 -0400 Received: from [194.166.82.229] ([194.166.82.229]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0xbD-1YR5zQ0rfD-00v7oc; Mon, 22 Sep 2014 19:43:47 +0200 Message-ID: <54205FCF.4050503@gmx.at> Date: Mon, 22 Sep 2014 19:43:43 +0200 From: martin rudalics MIME-Version: 1.0 References: <83egv3y90k.fsf@gnu.org> In-Reply-To: <83egv3y90k.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:72GwVBgvKAjTbjpmneIV+wXp0SuM0bI/vUppCVKOq7UpG6zAexU F5PdrfY/+yqjfd51fQUAakEjyBzJ2xHpArfsbaC4/QLXrJM3zrbfrpNPyu1W3lKvNVL0xRz ueFJtWnwLslUenLswjixjAnlRL70Jfo7vbbru5NZ0tLm0iodNuvYPmxrjfKBQ5/LnzvDEXW H6CeQLDGolouW4Oxoyk9w== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) > (gdb) p f->text_cols > $6 = -3 <<<<<<<<<<<<<<<<<<< What is the value of f->text_width here? > (We also don't check errors returned by > GetClientRect.) Should we? I wonder already why if (f && !FRAME_ICONIFIED_P (f) && msg.msg.wParam != SIZE_MINIMIZED) in w32_read_socket didn't catch this. > . change_frame_size internally validates the requested dimensions, > and doesn't allow them to become too small. But it does that on > pixel dimensions, and if those are corrected, the character-unit > dimensions are not recalculated to reflect those corrections. That's the bug. > + 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. > + ssize_t frame_message_buf_size = FRAME_MESSAGE_BUF_SIZE (f); > + > + eassert (frame_message_buf_size >= 0); Good. This part should definitely go to the trunk too. > + /* 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. Did you verify that the trunk handles your .emacs.desktop correctly? Many thanks, martin From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop 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: To: martin rudalics Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.141140967629821 (code B ref -1); Mon, 22 Sep 2014 18:15:02 +0000 Received: (at submit) by debbugs.gnu.org; 22 Sep 2014 18:14:36 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 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 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 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) 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) Date: Mon, 22 Sep 2014 21:13:53 +0300 From: Eli Zaretskii In-reply-to: <54205FCF.4050503@gmx.at> X-012-Sender: halo1@inter.net.il Message-id: <83bnq7y13y.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> 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-Received-From: 2001:4830:134:3::11 X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > 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. From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 05:50:01 +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: To: Eli Zaretskii Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14114513745443 (code B ref -1); Tue, 23 Sep 2014 05:50:01 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 05:49:34 +0000 Received: from localhost ([127.0.0.1]:49348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWIyk-0001Pi-2R for submit@debbugs.gnu.org; Tue, 23 Sep 2014 01:49:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41849) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWIyg-0001PZ-29 for submit@debbugs.gnu.org; Tue, 23 Sep 2014 01:49:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWIyV-0003n4-Sr for submit@debbugs.gnu.org; Tue, 23 Sep 2014 01:49:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWIyV-0003mY-Pn for submit@debbugs.gnu.org; Tue, 23 Sep 2014 01:49:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWIyI-0005Xs-VG for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 01:49:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWIyB-0003lL-Fu for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 01:49:06 -0400 Received: from mout.gmx.net ([212.227.17.20]:55636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWIy3-0003cv-EZ; Tue, 23 Sep 2014 01:48:51 -0400 Received: from [188.22.234.109] ([188.22.234.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LvPgd-1YEonf45at-010ZSi; Tue, 23 Sep 2014 07:48:45 +0200 Message-ID: <542109B8.6080107@gmx.at> Date: Tue, 23 Sep 2014 07:48:40 +0200 From: martin rudalics MIME-Version: 1.0 References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> In-Reply-To: <83bnq7y13y.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NM8X9ItUwu2mSEZ7Y+OJ4mFA5o1PiVVCNOrbI0U/+aU5FKgOC7j uKpYxXwS4QemKeCJirNCOKR50yL5m/HMi0TmrRYzbA/2M53A3dU28tbP9stXH+tbsXCtb79 cZXRRjcrHPojZ/Zig85ajx2CYuFgXICTdf1Uw4jaR9RwPf1tqs+CrVjdyL6mhmcUXxydju6 0kI+i4WaSSyywaGjHe0zQ== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) > 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. We have to check these values anyway because our window structure might be too complex to fit into the rectangle returned by GetClientRect. But then we should probably also rewrite things like w32_clear_window as if (hdc && GetClientRect (FRAME_W32_WINDOW (f), &rect)) w32_clear_rect (f, hdc, &rect); >> > + /* 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); I never got around to ask you: Do you anywhere see a need to round up the values of new_cols and new_lines in cases like this? martin From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 15:28: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: To: martin rudalics Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.141148602315188 (code B ref -1); Tue, 23 Sep 2014 15:28:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 15:27:03 +0000 Received: from localhost ([127.0.0.1]:50099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWRza-0003wt-Jq for submit@debbugs.gnu.org; Tue, 23 Sep 2014 11:27:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56159) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWRzY-0003wT-Or for submit@debbugs.gnu.org; Tue, 23 Sep 2014 11:27:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWRzS-0004es-VO for submit@debbugs.gnu.org; Tue, 23 Sep 2014 11:27:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWRzS-0004eS-Sl for submit@debbugs.gnu.org; Tue, 23 Sep 2014 11:26:54 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWRzI-0005zO-M1 for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 11:26:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWRzD-0004cJ-Ga for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 11:26:44 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:55027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWRzD-0004ba-8b for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 11:26:39 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NCD00E0017GRU00@mtaout29.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 18:26:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCD00BOM1JGKQ40@mtaout29.012.net.il>; Tue, 23 Sep 2014 18:26:04 +0300 (IDT) Date: Tue, 23 Sep 2014 18:26:27 +0300 From: Eli Zaretskii In-reply-to: <542109B8.6080107@gmx.at> X-012-Sender: halo1@inter.net.il Message-id: <8361gexsrg.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) > Date: Tue, 23 Sep 2014 07:48:40 +0200 > From: martin rudalics > CC: bug-gnu-emacs@gnu.org > > > 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. > > We have to check these values anyway because our window structure might > be too complex to fit into the rectangle returned by GetClientRect. Sorry, I don't think I understand this. GetClientRect just returns the dimensions of our frame, it doesn't know anything about Emacs windows. > But then we should probably also rewrite things like > w32_clear_window as > > if (hdc && GetClientRect (FRAME_W32_WINDOW (f), &rect)) > w32_clear_rect (f, hdc, &rect); Indeed. > >> > + /* 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); > > I never got around to ask you: Do you anywhere see a need to round up > the values of new_cols and new_lines in cases like this? Yes, I think so. I think the reason we didn't see any problems with that is that GUI windows always over-allocate their glyph matrices, to be prepared for dealing with the smallest possible font, which is rarely if ever used. But I think if you actually use that smallest font for the default face, you will see the problem. (Just make sure you don't round up for TTY frames, so as not to add one extra row there.) From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 16:17:01 +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: To: Eli Zaretskii Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.141148900025002 (code B ref -1); Tue, 23 Sep 2014 16:17:01 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 16:16:40 +0000 Received: from localhost ([127.0.0.1]:50134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWSlc-0006VC-21 for submit@debbugs.gnu.org; Tue, 23 Sep 2014 12:16:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40519) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWSlZ-0006V3-Ra for submit@debbugs.gnu.org; Tue, 23 Sep 2014 12:16:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWSlP-0001D3-K2 for submit@debbugs.gnu.org; Tue, 23 Sep 2014 12:16:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWSlP-0001Bk-HL for submit@debbugs.gnu.org; Tue, 23 Sep 2014 12:16:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWSlC-00007R-Tm for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 12:16:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWSl5-00018N-Cg for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 12:16:14 -0400 Received: from mout.gmx.net ([212.227.17.22]:59228) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWSkx-00016L-Co; Tue, 23 Sep 2014 12:15:59 -0400 Received: from [88.117.53.39] ([88.117.53.39]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MZxch-1XrhCQ1VaZ-00LmWW; Tue, 23 Sep 2014 18:15:53 +0200 Message-ID: <54219CB5.6080103@gmx.at> Date: Tue, 23 Sep 2014 18:15:49 +0200 From: martin rudalics MIME-Version: 1.0 References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> In-Reply-To: <8361gexsrg.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KAf2BNKf7iVrPnl26w1e6/kxrF4dZkPDSs08/S4FGZNSMSZ9QDF ofEk2hVFwAopunyUoTMs0NjR4M+JNHT4xrLvEaEKIXRTD28VubRsaNmSmObjfZkpgqksyVi 4JldKAFiKq7bWMbmu5nvGBGV99sgqbRqNJLJRoc7Z87RS5egkSEP6GqA1qE0LJOx6/ltE2D eIbhhBXPaNcvfSIQ2eisg== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) >> We have to check these values anyway because our window structure might >> be too complex to fit into the rectangle returned by GetClientRect. > > Sorry, I don't think I understand this. GetClientRect just returns > the dimensions of our frame, it doesn't know anything about Emacs > windows. If all values returned by GetClientRect are zero, it's all to obvious that our windows won't fit. But if, for example, rect.right - rect.left is too small to fit our windows, we face a similar same problem and have to handle that anyway. So I'm not sure whether we should separately deal with the case where all rectangle values are zero. >> I never got around to ask you: Do you anywhere see a need to round up >> the values of new_cols and new_lines in cases like this? > > Yes, I think so. I think the reason we didn't see any problems with > that is that GUI windows always over-allocate their glyph matrices, to > be prepared for dealing with the smallest possible font, which is > rarely if ever used. But I think if you actually use that smallest > font for the default face, you will see the problem. I thought it's not needed because in required_matrix_width we use the pixel width when HAVE_WINDOW_SYSTEM is defined. > (Just make sure you don't round up for TTY frames, so as not to add > one extra row there.) martin From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 19:00: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: To: martin rudalics Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.141149878323189 (code B ref -1); Tue, 23 Sep 2014 19:00:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 18:59:43 +0000 Received: from localhost ([127.0.0.1]:50244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVJO-00061w-Ip for submit@debbugs.gnu.org; Tue, 23 Sep 2014 14:59:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48036) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVJM-00061m-5M for submit@debbugs.gnu.org; Tue, 23 Sep 2014 14:59:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVJ4-0007RB-QR for submit@debbugs.gnu.org; Tue, 23 Sep 2014 14:59:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:40441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVJ4-0007KY-Ky for submit@debbugs.gnu.org; Tue, 23 Sep 2014 14:59:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWV6V-0006LB-Gk for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 14:46:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWV6Q-0003Iz-BW for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 14:46:23 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:48939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWV6Q-0003G6-3d for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 14:46:18 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NCD00B00AMTUR00@mtaout28.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 21:45:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCD006G7ARHDE50@mtaout28.012.net.il>; Tue, 23 Sep 2014 21:45:18 +0300 (IDT) Date: Tue, 23 Sep 2014 21:46:06 +0300 From: Eli Zaretskii In-reply-to: <54219CB5.6080103@gmx.at> X-012-Sender: halo1@inter.net.il Message-id: <83zjdqw4y9.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) > Date: Tue, 23 Sep 2014 18:15:49 +0200 > From: martin rudalics > CC: bug-gnu-emacs@gnu.org > > >> We have to check these values anyway because our window structure might > >> be too complex to fit into the rectangle returned by GetClientRect. > > > > Sorry, I don't think I understand this. GetClientRect just returns > > the dimensions of our frame, it doesn't know anything about Emacs > > windows. > > If all values returned by GetClientRect are zero, it's all to obvious > that our windows won't fit. But if, for example, rect.right - rect.left > is too small to fit our windows, we face a similar same problem and have > to handle that anyway. So I'm not sure whether we should separately > deal with the case where all rectangle values are zero. When they are zero, we know we shouldn't even call change_frame_size. > >> I never got around to ask you: Do you anywhere see a need to round up > >> the values of new_cols and new_lines in cases like this? > > > > Yes, I think so. I think the reason we didn't see any problems with > > that is that GUI windows always over-allocate their glyph matrices, to > > be prepared for dealing with the smallest possible font, which is > > rarely if ever used. But I think if you actually use that smallest > > font for the default face, you will see the problem. > > I thought it's not needed because in required_matrix_width we use the > pixel width when HAVE_WINDOW_SYSTEM is defined. Is this a response to what's above or to what's below? > > (Just make sure you don't round up for TTY frames, so as not to add > > one extra row there.) From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 19:18:01 +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: To: Eli Zaretskii Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.141149987625027 (code B ref -1); Tue, 23 Sep 2014 19:18:01 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 19:17:56 +0000 Received: from localhost ([127.0.0.1]:50257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVb1-0006Vb-Ma for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:17:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57552) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVb0-0006VT-AU for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:17:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVao-00069U-65 for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:17:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:37290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVao-00066e-3T for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:17:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVab-0006qy-IZ for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 15:17:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVaU-0005xt-1j for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 15:17:29 -0400 Received: from mout.gmx.net ([212.227.15.15]:62962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVaL-0005qr-Ss; Tue, 23 Sep 2014 15:17:14 -0400 Received: from [188.22.45.188] ([188.22.45.188]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M0y8F-1YQfwS1sX1-00v5dU; Tue, 23 Sep 2014 21:17:07 +0200 Message-ID: <5421C72E.7080405@gmx.at> Date: Tue, 23 Sep 2014 21:17:02 +0200 From: martin rudalics MIME-Version: 1.0 References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> In-Reply-To: <83zjdqw4y9.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/CD31Xwt+TF4/KCGspGrUYauuDL+AAA4VBYSS8LJlRlQnqZQyiW NppiVmJNfYzeqlIrYnQ4glcFlmxBK4E6XVVHh0cx2YfyCAj6o+qQERro6PEDMl+VggMCBh/ VcgsnKi2nekYWb4YDcgLrWORs5Nn+rAWiEP2De1P3K4eH15CfpG7AgxhUdAXcT6O2vTL0Qz 8IDOBZrJu9y5DPjOXnv7w== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) >> > Yes, I think so. I think the reason we didn't see any problems with >> > that is that GUI windows always over-allocate their glyph matrices, to >> > be prepared for dealing with the smallest possible font, which is >> > rarely if ever used. But I think if you actually use that smallest >> > font for the default face, you will see the problem. >> >> I thought it's not needed because in required_matrix_width we use the >> pixel width when HAVE_WINDOW_SYSTEM is defined. > > Is this a response to what's above or to what's below? To what's above. Currently we return (((WINDOW_PIXEL_WIDTH (w) + ch_width - 1) / ch_width) * w->ncols_scale_factor /* 2 partially visible columns in the text area. */ + 2 /* One partially visible column at the right edge of each marginal area. */ + 1 + 1); so columns aren't involved IIUC. martin From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 19:38: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: To: martin rudalics Cc: 18528@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.141150105927669 (code B ref -1); Tue, 23 Sep 2014 19:38:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Sep 2014 19:37:39 +0000 Received: from localhost ([127.0.0.1]:50269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVu6-0007CB-Gj for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:37:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38682) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVu4-0007C2-4E for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:37:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVtq-00073y-76 for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:37:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVtp-0006ml-UG for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:37:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVnt-0001R2-M6 for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 15:31:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVno-0002th-2V for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 15:31:13 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:40596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVnn-0002rO-JX for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 15:31:07 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NCD00200CIWNX00@mtaout27.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 23 Sep 2014 22:25:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCD00PO4CMH6H20@mtaout27.012.net.il>; Tue, 23 Sep 2014 22:25:29 +0300 (IDT) Date: Tue, 23 Sep 2014 22:30:55 +0300 From: Eli Zaretskii In-reply-to: <5421C72E.7080405@gmx.at> X-012-Sender: halo1@inter.net.il Message-id: <83vboew2vk.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> <5421C72E.7080405@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) > Date: Tue, 23 Sep 2014 21:17:02 +0200 > From: martin rudalics > CC: bug-gnu-emacs@gnu.org > > return (((WINDOW_PIXEL_WIDTH (w) + ch_width - 1) > / ch_width) * w->ncols_scale_factor > /* 2 partially visible columns in the text area. */ > + 2 > /* One partially visible column at the right > edge of each marginal area. */ > + 1 + 1); > > so columns aren't involved IIUC. I was talking about new_lines (you asked about both). From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Sep 2014 19:43: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: To: rudalics@gmx.at Cc: 18528@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18528-submit@debbugs.gnu.org id=B18528.141150137328398 (code B ref 18528); Tue, 23 Sep 2014 19:43:02 +0000 Received: (at 18528) by debbugs.gnu.org; 23 Sep 2014 19:42:53 +0000 Received: from localhost ([127.0.0.1]:50274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVzA-0007Nw-Iw for submit@debbugs.gnu.org; Tue, 23 Sep 2014 15:42:52 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:42077) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWVz7-0007Ni-LO for 18528@debbugs.gnu.org; Tue, 23 Sep 2014 15:42:50 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NCD00600CQNEA00@mtaout25.012.net.il> for 18528@debbugs.gnu.org; Tue, 23 Sep 2014 22:37:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCD000B1D72AN70@mtaout25.012.net.il>; Tue, 23 Sep 2014 22:37:50 +0300 (IDT) Date: Tue, 23 Sep 2014 22:42:43 +0300 From: Eli Zaretskii In-reply-to: <83vboew2vk.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83tx3yw2bw.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> <5421C72E.7080405@gmx.at> <83vboew2vk.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 23 Sep 2014 22:30:55 +0300 > From: Eli Zaretskii > Cc: 18528@debbugs.gnu.org > > > Date: Tue, 23 Sep 2014 21:17:02 +0200 > > From: martin rudalics > > CC: bug-gnu-emacs@gnu.org > > > > return (((WINDOW_PIXEL_WIDTH (w) + ch_width - 1) > > / ch_width) * w->ncols_scale_factor > > /* 2 partially visible columns in the text area. */ > > + 2 > > /* One partially visible column at the right > > edge of each marginal area. */ > > + 1 + 1); > > > > so columns aren't involved IIUC. > > I was talking about new_lines For which we do a similar calculation, I see. So now I don't understand why you asked about rounding up, since we evidently already do. From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Sep 2014 06:17: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: To: Eli Zaretskii Cc: 18528@debbugs.gnu.org Received: via spool by 18528-submit@debbugs.gnu.org id=B18528.14115394196070 (code B ref 18528); Wed, 24 Sep 2014 06:17:02 +0000 Received: (at 18528) by debbugs.gnu.org; 24 Sep 2014 06:16:59 +0000 Received: from localhost ([127.0.0.1]:50403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWfsp-0001Zp-3m for submit@debbugs.gnu.org; Wed, 24 Sep 2014 02:16:59 -0400 Received: from mout.gmx.net ([212.227.15.15]:56246) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWfsm-0001Zh-LX for 18528@debbugs.gnu.org; Wed, 24 Sep 2014 02:16:57 -0400 Received: from [91.113.4.91] ([91.113.4.91]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M5tU1-1YUREi2AeH-00xqBw; Wed, 24 Sep 2014 08:16:53 +0200 Message-ID: <542261CF.2080709@gmx.at> Date: Wed, 24 Sep 2014 08:16:47 +0200 From: martin rudalics MIME-Version: 1.0 References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> <5421C72E.7080405@gmx.at> <83vboew2vk.fsf@gnu.org> <83tx3yw2bw.fsf@gnu.org> In-Reply-To: <83tx3yw2bw.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:XoxIPHSA6UJI877OtBlyV8XhKQsQsXnewb86TySfJb4Pd/rlpRg gcO7Xrj54sY6oJSa3FxrzE8ipacqnR2RZp0UaLO2eqmGsp450wqijPiltgctaNnq4yOGUnQ 9gQIw1lFD1gVzG4wPbcGXly6YcP+ZvITjPyu0Acb+EwI7w7kcBtwGR5FXb7eyQ5OxlvLoxv /QhEoSwDAO4j0J7/uoGDA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > So now I don't understand why you asked about rounding up, since we > evidently already do. Not everywhere. For example, we don't in FRAME_MESSAGE_BUF_SIZE and FRAME_CURSOR_X_LIMIT. And the following check in compute_motion of indent.c seems dubious as well. if (!NILP (Vtruncate_partial_width_windows) && (total_width < FRAME_COLS (XFRAME (WINDOW_FRAME (win))))) martin From unknown Sat Jun 21 05:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18528: 24.3.93; Crash during restoration of frameset from desktop Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Sep 2014 07:16: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: To: martin rudalics Cc: 18528@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18528-submit@debbugs.gnu.org id=B18528.141154295812147 (code B ref 18528); Wed, 24 Sep 2014 07:16:02 +0000 Received: (at 18528) by debbugs.gnu.org; 24 Sep 2014 07:15:58 +0000 Received: from localhost ([127.0.0.1]:50417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWgnt-00039q-Pj for submit@debbugs.gnu.org; Wed, 24 Sep 2014 03:15:58 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:35841) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWgnq-00039f-5y for 18528@debbugs.gnu.org; Wed, 24 Sep 2014 03:15:55 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NCE0040097XTN00@mtaout25.012.net.il> for 18528@debbugs.gnu.org; Wed, 24 Sep 2014 10:10:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCE003CD9A6JD10@mtaout25.012.net.il>; Wed, 24 Sep 2014 10:10:54 +0300 (IDT) Date: Wed, 24 Sep 2014 10:15:48 +0300 From: Eli Zaretskii In-reply-to: <542261CF.2080709@gmx.at> X-012-Sender: halo1@inter.net.il Message-id: <83ppelwkt7.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> <5421C72E.7080405@gmx.at> <83vboew2vk.fsf@gnu.org> <83tx3yw2bw.fsf@gnu.org> <542261CF.2080709@gmx.at> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 24 Sep 2014 08:16:47 +0200 > From: martin rudalics > CC: 18528@debbugs.gnu.org > > > So now I don't understand why you asked about rounding up, since we > > evidently already do. > > Not everywhere. For example, we don't in FRAME_MESSAGE_BUF_SIZE and > FRAME_CURSOR_X_LIMIT. And the following check in compute_motion of > indent.c seems dubious as well. > > if (!NILP (Vtruncate_partial_width_windows) > && (total_width < FRAME_COLS (XFRAME (WINDOW_FRAME (win))))) That has nothing to do with rounding, does it? Anyway, FRAME_MESSAGE_BUF_SIZE has nothing to do with frame/window width, AFAIR, it is just computed based on the width. FRAME_CURSOR_X_LIMIT is used only for the echo area, so the probability of having a non-default font there is very low. We should probably do that calculation in pixels, though. As for the second example, I have a difficulty concocting a use case when it should matter, due to a combination of conditions that enter that block. But feel free to fix that if it sometimes gives bad results. From unknown Sat Jun 21 05:16:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#18528: closed (Re: bug#18528: 24.3.93; Crash during restoration of frameset from desktop) Message-ID: References: <83oau5wjyw.fsf@gnu.org> <83egv3y90k.fsf@gnu.org> X-Gnu-PR-Message: they-closed 18528 X-Gnu-PR-Package: emacs Reply-To: 18528@debbugs.gnu.org Date: Wed, 24 Sep 2014 07:35:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1411544103-13996-1" This is a multi-part message in MIME format... ------------=_1411544103-13996-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #18528: 24.3.93; Crash during restoration of frameset from desktop which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 18528@debbugs.gnu.org. --=20 18528: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18528 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1411544103-13996-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 18528-done) by debbugs.gnu.org; 24 Sep 2014 07:34:07 +0000 Received: from localhost ([127.0.0.1]:50424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWh5S-0003cT-QV for submit@debbugs.gnu.org; Wed, 24 Sep 2014 03:34:07 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:37155) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWh5Q-0003cK-2E for 18528-done@debbugs.gnu.org; Wed, 24 Sep 2014 03:34:05 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NCE00800A09J100@mtaout25.012.net.il> for 18528-done@debbugs.gnu.org; Wed, 24 Sep 2014 10:29:05 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCE00384A4HJD50@mtaout25.012.net.il> for 18528-done@debbugs.gnu.org; Wed, 24 Sep 2014 10:29:05 +0300 (IDT) Date: Wed, 24 Sep 2014 10:33:59 +0300 From: Eli Zaretskii Subject: Re: bug#18528: 24.3.93; Crash during restoration of frameset from desktop In-reply-to: <542261CF.2080709@gmx.at> X-012-Sender: halo1@inter.net.il To: 18528-done@debbugs.gnu.org Message-id: <83oau5wjyw.fsf@gnu.org> References: <83egv3y90k.fsf@gnu.org> <54205FCF.4050503@gmx.at> <83bnq7y13y.fsf@gnu.org> <542109B8.6080107@gmx.at> <8361gexsrg.fsf@gnu.org> <54219CB5.6080103@gmx.at> <83zjdqw4y9.fsf@gnu.org> <5421C72E.7080405@gmx.at> <83vboew2vk.fsf@gnu.org> <83tx3yw2bw.fsf@gnu.org> <542261CF.2080709@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18528-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) I've committed the patches to fix this bug in r11751 on the emacs-24 branch, and I'm closing the bug. ------------=_1411544103-13996-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 22 Sep 2014 15:23:58 +0000 Received: from localhost ([127.0.0.1]:49017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW5T2-000290-JR for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59398) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XW5Sz-00028r-Lf for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW5So-000545-QA for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5So-00053i-NO for submit@debbugs.gnu.org; Mon, 22 Sep 2014 11:23:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5Sc-00056Z-5V for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW5SU-000506-Gi for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:30 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:35387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW5ST-0004yg-Vc for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 11:23:22 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NCB00J0066ANJ00@mtaout24.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 18:17:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCB00IJO6HKHB20@mtaout24.012.net.il>; Mon, 22 Sep 2014 18:17:44 +0300 (IDT) Date: Mon, 22 Sep 2014 18:23:07 +0300 From: Eli Zaretskii Subject: 24.3.93; Crash during restoration of frameset from desktop X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <83egv3y90k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: submit Cc: martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) Today I started Emacs 24.3.93, and it crashed near the end of restoring the last session from .emacs.desktop, when it was re-creating the frames recorded in that file. Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. _malloc_internal_nolock (size=size@entry=4294967285) at gmalloc.c:897 897 gmalloc.c: No such file or directory. (gdb) bt 10 #0 _malloc_internal_nolock (size=size@entry=4294967285) at gmalloc.c:897 #1 0x011eff12 in _realloc_internal_nolock (ptr=0x3e89600, size=4294967285) at gmalloc.c:1441 #2 0x01123f22 in xrealloc (block=0x3e89600, size=4294967285) at alloc.c:717 #3 0x0100a25e in adjust_decode_mode_spec_buffer (f=) at dispnew.c:2106 #4 adjust_frame_glyphs (f=f@entry=0x418ca80) at dispnew.c:1756 #5 0x0100abd0 in change_frame_size_1 (f=0x418ca80, new_width=, new_height=, pretend=pretend@entry=false, delay=delay@entry=false, safe=safe@entry=false, pixelwise=pixelwise@entry=true) at dispnew.c:5596 #6 0x0100cc89 in change_frame_size (pixelwise=true, safe=, delay=false, pretend=false, new_height=, new_width=, f=) at dispnew.c:5471 #7 do_pending_window_change (safe=safe@entry=false) at dispnew.c:5432 #8 0x0100e9e8 in Fset_frame_size (frame=frame@entry=104658605, width=2880, height=3740, pixelwise=65550402) at frame.c:2645 #9 0x010126ad in x_set_frame_parameters (f=f@entry=0x63cf6a8, alist=) at frame.c:3002 (More stack frames follow...) (gdb) frame 4 #4 adjust_frame_glyphs (f=f@entry=0x418ca80) at dispnew.c:1756 1756 in dispnew.c (gdb) p/x f $5 = 0x418ca80 (gdb) p f->text_cols $6 = -3 <<<<<<<<<<<<<<<<<<< As you can see, the text_cols member is negative. This is the immediate cause of the crash, because adjust_decode_mode_spec_buffer does this: static void adjust_decode_mode_spec_buffer (struct frame *f) { f->decode_mode_spec_buffer = xrealloc (f->decode_mode_spec_buffer, FRAME_MESSAGE_BUF_SIZE (f) + 1); } and FRAME_MESSAGE_BUF_SIZE is defined like this: #define FRAME_MESSAGE_BUF_SIZE(f) (((int) FRAME_COLS (f)) * 4) So we pass a negative value to xrealloc, which interprets it as a very large positive value, with predictable results. Some digging into this reveals the following: . The negative values come from w32term.c, around line 4770, where they are derived from the value returned by GetClientRect. Evidently, it sometimes returns a (0, 0, 0, 0) rectangle for the frame dimensions, from which we then subtract the dimensions of frame decorations, like scroll bar etc., and call change_frame_size. (We also don't check errors returned by GetClientRect.) . change_frame_size internally validates the requested dimensions, and doesn't allow them to become too small. But it does that on pixel dimensions, and if those are corrected, the character-unit dimensions are not recalculated to reflect those corrections. Below please find a patch that I intend to commit to the emacs-24 branch if no one objects. Martin, I'd appreciate your review, especially for the dispnew.c parts. TIA --- src/w32term.c~0 2014-05-24 23:48:43 +0300 +++ src/w32term.c 2014-09-21 17:48:00 +0300 @@ -4754,34 +4754,42 @@ w32_read_socket (struct terminal *termin RECT rect; int rows, columns, width, height, text_width, text_height; - GetClientRect (msg.msg.hwnd, &rect); - - height = rect.bottom - rect.top; - width = rect.right - rect.left; - text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, width); - text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, height); - rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, height); - columns = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, width); - - /* TODO: Clip size to the screen dimensions. */ - - /* Even if the number of character rows and columns has - not changed, the font size may have changed, so we need - to check the pixel dimensions as well. */ - - if (width != FRAME_PIXEL_WIDTH (f) - || height != FRAME_PIXEL_HEIGHT (f) - || text_width != FRAME_TEXT_WIDTH (f) - || text_height != FRAME_TEXT_HEIGHT (f)) + 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)) { - change_frame_size (f, text_width, text_height, 0, 1, 0, 1); - SET_FRAME_GARBAGED (f); - cancel_mouse_face (f); - /* Do we want to set these here ???? */ -/** FRAME_PIXEL_WIDTH (f) = width; **/ -/** FRAME_TEXT_WIDTH (f) = text_width; **/ -/** FRAME_PIXEL_HEIGHT (f) = height; **/ - f->win_gravity = NorthWestGravity; + height = rect.bottom - rect.top; + width = rect.right - rect.left; + text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, width); + text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, height); + rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, height); + columns = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, width); + + /* TODO: Clip size to the screen dimensions. */ + + /* Even if the number of character rows and columns + has not changed, the font size may have changed, + so we need to check the pixel dimensions as well. */ + + if (width != FRAME_PIXEL_WIDTH (f) + || height != FRAME_PIXEL_HEIGHT (f) + || text_width != FRAME_TEXT_WIDTH (f) + || text_height != FRAME_TEXT_HEIGHT (f)) + { + change_frame_size (f, text_width, text_height, 0, 1, 0, 1); + SET_FRAME_GARBAGED (f); + cancel_mouse_face (f); + /* Do we want to set these here ???? */ + /** FRAME_PIXEL_WIDTH (f) = width; **/ + /** FRAME_TEXT_WIDTH (f) = text_width; **/ + /** FRAME_PIXEL_HEIGHT (f) = height; **/ + f->win_gravity = NorthWestGravity; + } } } --- src/dispnew.c~1 2014-08-17 07:29:32 +0300 +++ src/dispnew.c 2014-09-22 17:40:15 +0300 @@ -2139,8 +2139,11 @@ adjust_frame_glyphs_for_window_redisplay static void adjust_decode_mode_spec_buffer (struct frame *f) { + ssize_t frame_message_buf_size = FRAME_MESSAGE_BUF_SIZE (f); + + eassert (frame_message_buf_size >= 0); f->decode_mode_spec_buffer = xrealloc (f->decode_mode_spec_buffer, - FRAME_MESSAGE_BUF_SIZE (f) + 1); + frame_message_buf_size + 1); } @@ -5540,10 +5543,6 @@ change_frame_size_1 (struct frame *f, in { new_text_width = (new_width == 0) ? FRAME_TEXT_WIDTH (f) : new_width; new_text_height = (new_height == 0) ? FRAME_TEXT_HEIGHT (f) : new_height; - /* 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); } else { @@ -5556,6 +5555,12 @@ change_frame_size_1 (struct frame *f, in /* Compute width of windows in F. */ /* Round up to the smallest acceptable size. */ check_frame_size (f, &new_text_width, &new_text_height, 1); + /* 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 is the width of the frame without vertical scroll bars and fringe columns. Do this after rounding - see discussion of In GNU Emacs 24.3.93.1 (i686-pc-mingw32) of 2014-08-15 on HOME-C4E4A596F7 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-Og -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e o p p o r t - e m Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 74217 7009) (symbols 32 17535 0) (miscs 32 33 127) (strings 16 10776 4344) (string-bytes 1 269654) (vectors 8 9550) (vector-slots 4 384749 6002) (floats 8 57 196) (intervals 28 237 95) (buffers 508 11)) ------------=_1411544103-13996-1--