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

Previous Next

Package: emacs;

Reported by: Joseph Jones <josejones <at> expedia.com>

Date: Mon, 10 Oct 2011 23:43:02 UTC

Severity: normal

Found in version 24.0.50

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Jones <josejones <at> expedia.com>
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
Date: Tue, 31 Jan 2012 19:43:32 +0200
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 13:50:24 -0800
> 
> (gdb) p w->total_cols
> $8 = 0
> (gdb) p w->left_margin_cols
> $9 = 24
> (gdb) xtype
> Lisp_Int0
> (gdb)

Thanks.  This is very strange.  Look at the last portion of 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
> #9  0x0104b89e in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54749210,
>     wait_proc=0x0, just_wait_proc=0) at process.c:4673

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 question is now which code requested the change of window width to
-2, and why.

Could you please run Emacs again under GDB, but this time set a
breakpoint before starting Emacs.  That is, after starting the
debugger, and before running Emacs with the "run" command, set a
breakpoint like this:

  (gdb) break dispnew.c: 5751 if f->new_text_cols < 2
  (gdb) run

Line 5751 is where Emacs delays window size changes, to be performed
later by do_pending_window_change.  Here's the relevant fragment:

  /* If we can't deal with the change now, queue it for later.  */
  if (delay || (redisplaying_p && !safe))
    {
      f->new_text_lines = newheight;
      f->new_text_cols = newwidth;
      delayed_size_change = 1;
      return;
    }

I would like to know which code sets f->new_text_cols to bogus values.
If the above breakpoint ever breaks, please type "bt" and post the
results here.

Thanks.

(You can now stop the session that you left in GDB.)




This bug report was last modified 13 years and 7 days ago.

Previous Next


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