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

Previous Next

Full log

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

From: Joseph Jones <josejones <at> expedia.com>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
Subject: RE: bug#9723: 24.0.50; Emacs Clipboard crash
Date: Thu, 2 Feb 2012 09:08:51 -0800

My thought exactly, but it would be interesting to know why it is trying to set a bad size in the first place. Given my abilities to keep debug sessions running, though, I would vote to go with the defensive fix and correct or abort an invalid resize.

-----Original Message-----
From: martin rudalics [mailto:rudalics <at> gmx.at] 
Sent: Thursday, February 02, 2012 3:09 AM
To: Eli Zaretskii
Cc: Joseph Jones; 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash

 > 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.  Why do you think it's too small?

 > 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?

martin

Previous Next

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