bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[Michael Welsh Duggan]

If I run "emacs -Q" multiple times in a row with the build described
below in an X environment, I normally get a frame that my window manager
describes as 80x34 characters in size.

However, about one in every ten times, I get a differently sized frame,
usually 84x36.  (And that is indeed the width in chars.)

To repeat, in order to reproduce this I run emacs -Q, check its size,
then type `C-x C-c' and do it again until I see this happening.  This is
also happening to me at work on an older system (Gnome 2 instead of
Gnome 3), with a slightly older (but still recent) build of master.


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit)
 of 2014-11-27 on maru2
Repository revision: 1e3e8ae1d6da51606bf099e5cf02d6ab1f0c27ec
Windowing system distributor `The X.Org Foundation', version 11.0.11602901
System Description:	Debian GNU/Linux 8.0 (jessie)

Configured using:
 `configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
 'CFLAGS=-Og -ggdb -g3' --with-wide-int'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[Michael Welsh Duggan]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

I was able to bisect this problem to commit
3477e27021dbe9366c3c1aaba80feb72f1138b29

"Complete pixelwise frame/window resizing, add horizontal scrollbar
support."

I am testing for the bad behavior using the following script:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test.sh --]
[-- Type: text/x-sh, Size: 240 bytes --]

#!/bin/bash

EMACS=/home/md5i/src/emacs/build/src/emacs
BUGTEST=/tmp/bug.el

for run in {1..50}
do
    ${EMACS} -Q -l ${BUGTEST}
    cols=$?
    if [ $cols -ne 80 ]; 
    then
        echo "Width == $cols"
        exit 1
    fi
done
exit 0

[-- Attachment #3: Type: text/plain, Size: 60 bytes --]


The following is the elisp file referenced in the script:


[-- Attachment #4: bug.el --]
[-- Type: application/emacs-lisp, Size: 177 bytes --]

[-- Attachment #5: Type: text/plain, Size: 761 bytes --]


Finally, here is example output from a few runs:

md5i@maru2:~/src/emacs/build$ /tmp/test.sh 
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Width == 84
md5i@maru2:~/src/emacs/build$ /tmp/test.sh 
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Width == 84
md5i@maru2:~/src/emacs/build$ /tmp/test.sh 
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Width == 84

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[martin rudalics]

 > If I run "emacs -Q" multiple times in a row with the build described
 > below in an X environment, I normally get a frame that my window manager
 > describes as 80x34 characters in size.
 >
 > However, about one in every ten times, I get a differently sized frame,
 > usually 84x36.  (And that is indeed the width in chars.)

Please do `M-: (window--dump-frame)' on both frame types and post the
contents of the buffer *window-frame-dump* for both cases so we can see
where we spend the extra space.

 > To repeat, in order to reproduce this I run emacs -Q, check its size,
 > then type `C-x C-c' and do it again until I see this happening.  This is
 > also happening to me at work on an older system (Gnome 2 instead of
 > Gnome 3), with a slightly older (but still recent) build of master.

Please do the same there and post the results as well.  Does/did it
happen with Emacs 24.4 too or do you see it only on Emacs 25?

 > In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit)
 >   of 2014-11-27 on maru2
 > Repository revision: 1e3e8ae1d6da51606bf099e5cf02d6ab1f0c27ec
 > Windowing system distributor `The X.Org Foundation', version 11.0.11602901
 > System Description:	Debian GNU/Linux 8.0 (jessie)
 >
 > Configured using:
 >   `configure --without-toolkit-scroll-bars --with-x-toolkit=lucid

It should be related to the combination of these options.  But maybe it
happens to other users as well and they simply ignore it.

 >   'CFLAGS=-Og -ggdb -g3' --with-wide-int'

Thanks, martin

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[Michael Welsh Duggan]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

martin rudalics <rudalics@gmx.at> writes:

>> If I run "emacs -Q" multiple times in a row with the build described
>> below in an X environment, I normally get a frame that my window manager
>> describes as 80x34 characters in size.
>>
>> However, about one in every ten times, I get a differently sized frame,
>> usually 84x36.  (And that is indeed the width in chars.)
>
> Please do `M-: (window--dump-frame)' on both frame types and post the
> contents of the buffer *window-frame-dump* for both cases so we can see
> where we spend the extra space.

Good:

[-- Attachment #2: good.txt --]
[-- Type: text/plain, Size: 892 bytes --]

frame pixel: 756 x 682   cols/lines: 84 x 34   units: 9 x 19
frame text pixel: 720 x 646   cols/lines: 80 x 34
tool: 36  scroll: 18/0  fringe: 16  border: 1  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 34   size: 754 x 627   new: 0
char left: 0   top: 1   size: 83 x 33   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 720 x 608   char: 80 x 32
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 18  divider: 0
height header-line: 0  mode-line: 19  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 661   size: 754 x 19   new: 0
char left: 0   top: 34   size: 754 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 720 x 19   char: 80 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 18  divider: 0
height header-line: 0  mode-line: 0  divider: 0


[-- Attachment #3: Type: text/plain, Size: 6 bytes --]


Bad:

[-- Attachment #4: bad.txt --]
[-- Type: text/plain, Size: 892 bytes --]

frame pixel: 792 x 720   cols/lines: 88 x 36   units: 9 x 19
frame text pixel: 756 x 684   cols/lines: 84 x 36
tool: 36  scroll: 18/0  fringe: 16  border: 1  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 34   size: 790 x 665   new: 0
char left: 0   top: 1   size: 87 x 35   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 756 x 646   char: 84 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 18  divider: 0
height header-line: 0  mode-line: 19  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 699   size: 790 x 19   new: 0
char left: 0   top: 36   size: 790 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 756 x 19   char: 84 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 18  divider: 0
height header-line: 0  mode-line: 0  divider: 0


[-- Attachment #5: Type: text/plain, Size: 1271 bytes --]


>> To repeat, in order to reproduce this I run emacs -Q, check its size,
>> then type `C-x C-c' and do it again until I see this happening.  This is
>> also happening to me at work on an older system (Gnome 2 instead of
>> Gnome 3), with a slightly older (but still recent) build of master.
>
> Please do the same there and post the results as well.  Does/did it
> happen with Emacs 24.4 too or do you see it only on Emacs 25?

I am unable to test this on the other system this week.  I made a build
from the emacs-24 branch on this machine (the one referenced below), and
I was unable to trigger this bug there.

>> In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit)
>>   of 2014-11-27 on maru2
>> Repository revision: 1e3e8ae1d6da51606bf099e5cf02d6ab1f0c27ec
>> Windowing system distributor `The X.Org Foundation', version 11.0.11602901
>> System Description:	Debian GNU/Linux 8.0 (jessie)
>>
>> Configured using:
>>   `configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
>
> It should be related to the combination of these options.  But maybe it
> happens to other users as well and they simply ignore it.
>
>>   'CFLAGS=-Og -ggdb -g3' --with-wide-int'
>
> Thanks, martin

Thanks for looking into this.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[martin rudalics]

The following excerpts are from
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19428#18.  Sorry, but
gmx.de refused to pass on some of the previous postings.

 > I was able to bisect this problem to commit
 > 3477e27021dbe9366c3c1aaba80feb72f1138b29
 >
 > "Complete pixelwise frame/window resizing, add horizontal scrollbar
 > support."

Thanks for bisecting this.  Highly appreciated (even if the result was
somewhat predictable).

 > Good:
 >
 > [good.txt (text/plain, inline)]
 >
 > frame pixel: 756 x 682   cols/lines: 84 x 34   units: 9 x 19
 > frame text pixel: 720 x 646   cols/lines: 80 x 34
 > tool: 36  scroll: 18/0  fringe: 16  border: 1  right: 0  bottom: 0
 > [...]
 > Bad:
 >
 > [bad.txt (text/plain, inline)]
 >
 > frame pixel: 792 x 720   cols/lines: 88 x 36   units: 9 x 19
 > frame text pixel: 756 x 684   cols/lines: 84 x 36
 > tool: 36  scroll: 18/0  fringe: 16  border: 1  right: 0  bottom: 0

The good and bad values are so hilariously different that some silly
code must have been at work here.  I checked in a fix on master/trunk
with commit 8c38c2b77a5f0b256948bda0d3f9b6272483a42d.  Please try it.

Thanks for all your work on this, martin

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[Michael Duggan]

> On Jan 3, 2015, at 12:17, martin rudalics <rudalics@gmx.at> wrote:
> 
> The good and bad values are so hilariously different that some silly
> code must have been at work here.  I checked in a fix on master/trunk
> with commit 8c38c2b77a5f0b256948bda0d3f9b6272483a42d.  Please try it.

Thanks for looking into this.  I can confirm that I have been unable to trigger the problem after this modification. 

-- 
Michael Duggan

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[martin rudalics]

 >> The good and bad values are so hilariously different that some silly
 >> code must have been at work here.  I checked in a fix on master/trunk
 >> with commit 8c38c2b77a5f0b256948bda0d3f9b6272483a42d.  Please try it.
 >
 > Thanks for looking into this.  I can confirm that I have been unable to trigger the problem after this modification.

OK.  Closing this bug.

While you're there - can you please send me the following values
obtained after invoking today's emacs -Q:

- The contents of the buffer *window-frame-dump* after doing
   M-: (window--dump-frame)

- The value of evaluating (x-frame-geometry)

- The value of the variable `frame-initial-frame-tool-bar-height'

Thanks, martin

bug#19428: 25.0.50; Frame is wider (in chars) than normal non-deterministically

[martin rudalics]

> Closing this bug.

... next try.

martin

bug#19428: 25.0.50; X frame size inconsistent at start-up

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

Martin's patch caused GCC to complain if --enable-gcc-warnings is used; I 
installed the attached minor further change.

[-- Attachment #2: 0001-Pacify-gcc-Wparentheses.patch --]
[-- Type: text/x-diff, Size: 1319 bytes --]

From 756acc864ade7f842109bd2d5f6f9a5b0a9e3153 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 3 Jan 2015 12:19:00 -0800
Subject: [PATCH] Pacify gcc -Wparentheses

* frame.c (x_set_frame_parameters): Add parens (Bug#19428).
---
 src/ChangeLog | 5 +++++
 src/frame.c   | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/ChangeLog b/src/ChangeLog
index 6d25fc2..12852b8 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-03  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Pacify gcc -Wparentheses
+	* frame.c (x_set_frame_parameters): Add parens (Bug#19428).
+
 2015-01-03  Martin Rudalics  <rudalics@gmx.at>
 
 	* frame.c (x_set_frame_parameters): Call Fset_frame_size only if
diff --git a/src/frame.c b/src/frame.c
index bdc914f..5a0d142 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3219,7 +3219,7 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
 
     if ((width_change && width != FRAME_TEXT_WIDTH (f))
 	|| (height_change && height != FRAME_TEXT_HEIGHT (f))
-	|| f->can_x_set_window_size && (f->new_height || f->new_width))
+	|| (f->can_x_set_window_size && (f->new_height || f->new_width)))
       {
 	/* If necessary provide default values for HEIGHT and WIDTH.  Do
 	   that here since otherwise a size change implied by an
-- 
2.1.0

bug#19428: 25.0.50; X frame size inconsistent at start-up

[martin rudalics]

 > Martin's patch caused GCC to complain if --enable-gcc-warnings is used; I installed the attached minor further change.

Thanks.  In the past I always built with warnings enabled but had to
disable them a couple of weeks ago: Some code had been injected which
caused making stop here because of warnings treated as errors and I had
no idea how to ignore them and continue compiling.

BTW I'm strongly in favour ...

   ... to change the defaults for Emacs's build procedure
   to generate less output, to help builders and developers focus more
   easily on the diagnostics and warnings that are worth paying attention
   to.

as in the report for bug#19501.  Warnings are typical for such behavior
because they (1) generate too much output and (2) can stop compiling in
a pretty obscure way.

martin

bug#19428: 25.0.50; X frame size inconsistent at start-up

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

martin rudalics wrote:
> Some code had been injected which
> caused making stop here because of warnings treated as errors and I had
> no idea how to ignore them and continue compiling.

You can use 'make WERROR_CFLAGS=' for that.  I installed the attached patch to 
document this better.

Warnings shouldn't happen with the latest GCC (4.9.2) on x86-64 GNU/Linux, but 
they can happen with older compilers or other platforms.

[-- Attachment #2: 0001-INSTALL-Mention-make-WERROR_CFLAGS.patch --]
[-- Type: text/x-diff, Size: 1375 bytes --]

From 611310ec5029aa2b5de74a70733b3cd7106034b9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 4 Jan 2015 01:10:26 -0800
Subject: [PATCH] * INSTALL: Mention 'make WERROR_CFLAGS='.

---
 ChangeLog | 2 ++
 INSTALL   | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 8051263..36edfe6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,7 @@
 2015-01-04  Paul Eggert  <eggert@cs.ucla.edu>
 
+	* INSTALL: Mention 'make WERROR_CFLAGS='.
+
 	Clarify 'make info'
 	* Makefile.in (info): Use GNU make conditional rather than
 	an '@' rule with a shell conditional, so that the builder can
diff --git a/INSTALL b/INSTALL
index 6850c7d..1ed2698 100644
--- a/INSTALL
+++ b/INSTALL
@@ -312,7 +312,9 @@ Use --enable-gcc-warnings to enable compile-time checks that warn
 about possibly-questionable C code.  This is intended for developers
 and is useful with GNU-compatible compilers.  On a recent GNU system
 there should be no warnings; on older and on non-GNU systems the
-generated warnings may still be useful.
+generated warnings may still be useful, though you may prefer building
+with 'make WERROR_CFLAGS=' so that the warnings are not treated as
+errors.
 
 Use --enable-silent-rules to cause 'make' to chatter less.  This is
 helpful when combined with options like --enable-gcc-warnings that
-- 
2.1.0