GNU bug report logs - #18912
24.4; mode-line corruption on graphical frames in dual-headed display

Previous Next

Full log

Message #71 received at 18912 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 18912 <at> debbugs.gnu.org
Subject: Re: bug#18912: 24.4; mode-line corruption on graphical frames
 in dual-headed display
Date: Mon, 03 Nov 2014 18:06:28 -0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> I'd like to solve this problem, not paper over it.  I hope you agree
> that solving it is better than working around it.

Sure, given that it's practical to solve.

> I find it hard to believe that we won't find the root cause, so I
> think we don't need to consider that possibility.

I'm glad to hear it!  I'll do whatever I can to help you figure this
out. :-)

> Here are the first instructions to get information that will help us
> start digging into this.  (These are in addition to what Martin
> already requested.)

I've replied to Martin's request already.

> First, please build Emacs without optimizations and with extra
> checking code enabled:
> 
>   CFLAGS='-O0 -g3' ./configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena --enable-checking='yes,glyphs'
> 
> (I only care about CFLAGS and the --enable-checking= option; the rest
> I just copied from your original report, but feel free to change them
> if you want.  The --enable-checking= option is required to compile the
> dump-glyph-matrix command I ask you to use below.)

Here is what Emacs says about the configuration step:

  Configured using:
   `configure --prefix=/home/felix/opt/emacs-24.4-debug
  --with-x-toolkit=athena --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''

I did a VPATH build, though.

> After 'configure' finishes, invoke "make".  You don't have to invoke
> "make install", as Emacs can be run from the src/ directory where it
> was built.

I did that: ran it right away from the build directory.

> Now start Emacs you've just build with "emacs -Q", type the "C-x d"
> command that you say is sufficient to reproduce the problem, and then
> type this:
> 
>   M-x dump-glyph-matrix RET
> 
> This outputs to the standard error stream the description of the
> internal data structure, called "glyph matrix", which Emacs maintains
> for each window on a GUI frame.  Please post that output (you may wish
> to redirect stderr to a file when you invoke Emacs, to make that
> easier).
> 
> Please do this once for the "good" configuration, and another time for
> the "bad" configuration, but please make sure you invoke Emacs the
> same in both cases and type the same "C-x d" command in each case.

The outputs of the 'dump-glyph-matrix' command for both the good and bad
configurations are in the attached files 'dump-glyph-matrix-good.txt'
and 'dump-glyph-matrix-bad.txt', respectively; they are identical, though.

> Next, in the "bad" configuration and with the listing of /dev and
> corrupted mode line displayed, type this:
> 
>   M-: (setq frame-resize-pixelwise t) RET
> 
> Now carefully decrease the frame's height by dragging its upper or
> lower edge with the mouse.  Please drag it slowly and carefully, so
> that the frame is resized one pixel at a time.  After each resize,
> please see if the mode line is no longer corrupted.  Perhaps kill the
> buffer and type "C-x d" again to make sure the corruption disappeared
> for good.  The first time the mode line stops being corrupted, type
> 
>   M-x dump-glyph-matrix RET
> 
> again, and include this (3rd) output in your message.  Also, please
> tell how many pixels did you subtract from the original frame height
> before the corruption disappeared (assuming it ever does).

For the sake of precision I used the method suggested by Martin:
evaluating the expression

(while (y-or-n-p "decrease?")
  (set-frame-height nil (1- (frame-text-height)) nil t))

in the requested condition.  In order to not be fooled by a spurious
mode-line redrawing, I killed the buffer and invoked 'C-x d /dev RET'
again and the glitch was gone, after one iteration (minus 1 pixel).  The
output of the command 'dump-glyph-matrix' is in the attached file named
'dump-glyph-matrix-bad-resized.txt'.  This one is different from the
other two.

Then, to be sure I executed immediately the inverse procedure by
evaluating the expression

(while (y-or-n-p "increase?")
  (set-frame-height nil (1+ (frame-text-height)) nil t))

and therefore incrementing the frame's height by 1 pixel.  After killing
and getting again to the Dired buffer, the glitch was back.

> Where are the instructions to use the debugger, you ask?  Well, not
> yet, but maybe after we see what the above tells us.

I'm waiting for further instructions. :-P

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;

[dump-glyph-matrix-bad.txt (text/plain, attachment)]

[dump-glyph-matrix-bad-resized.txt (text/plain, attachment)]

[dump-glyph-matrix-good.txt (text/plain, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.