GNU bug report logs - #9723
24.0.50; Emacs Clipboard crash

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
Subject: bug#9723: 24.0.50; Emacs Clipboard crash
Date: Thu, 02 Feb 2012 19:06:19 +0200

> Date: Thu, 02 Feb 2012 12:08:34 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Joseph Jones <josejones <at> expedia.com>, 9723 <at> debbugs.gnu.org
> 
>  > According to this, Emacs decided to apply a change in window
>  > dimensions that was pending from some previous redisplay cycle.  So
>  > far so good, but look at the new size of the window it tries to set:
>  > its newwidth value is -2, a negative number.  This should never
>  > happen.  (The value -2 is "upgraded" to +2, the minimum "safe" value,
>  > inside change_frame_size, but 2 is also too small.)
> 
> The upgrading happens in check_frame_size and 2 is the minimum width
> sufficient for the frame's root window.

Yes, I know, this is clearly visible in the backtrace.

> Why do you think it's too small?

Because it causes the assertion violation anyway.

>  > The question is now which code requested the change of window width to
>  > -2, and why.
> 
> If you know what the minimum "safe" value is, why not use that?

I'm not sure yet that I know what is the safe value.  I'd appreciate
some help, if you can.  Look at the backtrace:

  #1  0x010ea4c8 in adjust_glyph_matrix (w=0x5b20a00, matrix=0x57b9480, x=0, y=0, dim=...) at dispnew.c:493
  #2  0x010eddb2 in allocate_matrices_for_window_redisplay (w=0x5b20a00) at dispnew.c:1867
  #3  0x010eec1d in adjust_frame_glyphs_for_window_redisplay (f=0x3903c00) at dispnew.c:2196
  #4  0x010ee208 in adjust_frame_glyphs (f=0x3903c00) at dispnew.c:1944
  #5  0x010ede82 in adjust_glyphs (f=0x3903c00) at dispnew.c:1889
  #6  0x010f7aa7 in change_frame_size_1 (f=0x3903c00, newheight=65, newwidth=2, pretend=0, delay=0, safe=0) at dispnew.c:5826
  #7  0x010f772b in change_frame_size (f=0x0, newheight=0, newwidth=-2, pretend=0, delay=0, safe=0) at dispnew.c:5736
  #8  0x010f74e0 in do_pending_window_change (safe=0) at dispnew.c:5702

If newwidth is 2 (in frame 6), then how come w->total_cols becomes
zero by the time it gets to adjust_glyph_matrix?  Joseph reported
these values:

  w->left_margin_cols = 24
  w->total_cols = 0

How did that happen, in a window that is just 2 columns wide??  If
that's legit, then 2 is too small; or else we have yet another bug on
our hands.

TIA

Previous Next

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