bug#9904: 24.0.90; Crash in show_mouse_face

bug#9904: 24.0.90; Crash in show_mouse_face

[Johan Bockgård]

Emacs segfaulted in show_mouse_face last week (revno 106154, I
think). I have a core file.

hlinfo->mouse_face_window is non-nil but contains garbage.


Program terminated with signal 11, Segmentation fault.
(gdb) core-file ~/core 
#0  0x00007f49f8cdf687 in kill () at ../sysdeps/unix/syscall-template.S:82
No locals.
#1  0x00000000005046dc in fatal_error_signal (sig=<optimized out>) at emacs.c:358
No locals.
#2  fatal_error_signal (sig=<optimized out>) at emacs.c:328
No locals.
#3  <signal handler called>
No symbol table info available.
#4  0x000000000045988a in show_mouse_face (hlinfo=0xdc2578, draw=DRAW_NORMAL_TEXT) at xdisp.c:25508
        phys_cursor_on_p = 1
        row = 0x7a32000000000684
        first = 0x7a32000000000684
        last = 0x7a32000000000684
        w = 0x1f5f020
        f = 0x2087020
#5  0x0000000000459f44 in clear_mouse_face (hlinfo=0xdc2578) at xdisp.c:25620
        cleared = 0
#6  0x000000000045a43d in note_mouse_highlight (f=0x12111b0, x=245, y=626) at xdisp.c:26850
        hlinfo = 0xdc2578
        part = ON_TEXT
        window = 18945077
        w = <optimized out>
        cursor = 0
        pointer = 12024322
        b = <optimized out>
[...]
#7  0x00000000004c1268 in note_mouse_movement (frame=0x12111b0, event=0x7fff1ffd9db0) at xterm.c:3830
#8  0x00000000004c93df in handle_one_xevent (dpyinfo=0xdc24d0, eventptr=0x7fff1ffda180, finish=0xaf9478, hold_quit=0x7fff1ffda670) at xterm.c:6752
#9  0x00000000004cab32 in event_handler_gdk (gxev=0x7fff1ffda180, ev=<optimized out>, data=<optimized out>) at xterm.c:5821


(gdb) fr 4
#4  0x000000000045988a in show_mouse_face (hlinfo=0xdc2578, 
    draw=DRAW_NORMAL_TEXT) at xdisp.c:25508
25508         for (row = first; row <= last && row->enabled_p; ++row)

(gdb) p *row
Cannot access memory at address 0x7a32000000000684

(gdb) p *w->current_matrix 
$9 = {
  pool = 0x8c81000000000000, 
  rows = 0x7a32000000000084, 
  rows_allocated = 8778078623698518199, 
  nrows = 183, 
  matrix_x = -969539584, 
  matrix_y = 202, 
  matrix_w = 0, 
  matrix_h = 0, 
  window_left_col = 8912896, 
  window_top_line = 0, 
  window_height = -1935605760, 
  window_width = 132, 
  window_vscroll = 2043805696, 
  left_margin_glyphs = 183, 
  right_margin_glyphs = 2043805696, 
  no_scrolling_p = 1, 
  header_line_p = 1, 
  buffer = 0xb7, 
  begv = 0, 
  zv = 8912896
}

(gdb) p hlinfo->mouse_face_window 
$84 = 32895013
(gdb) xtype
Lisp_Vectorlike
11859264

Expected
PVEC_WINDOW

(gdb) p *w
$53 = {
  header = {
    size = 11859264, 
    next = {
      buffer = 0xb4f540, 
      vector = 0xb4f540
    }
  }, 
  frame = 34107424, 
  mini_p = 34107232, 
  next = 34107344, 
  prev = 30064771073, 
  hchild = 33447270, 
  vchild = 49, 
  parent = 2, 
  left_col = 34416992, 
  top_line = 34426450, 
  total_lines = 12024370, 
  total_cols = 48, 
  normal_lines = 81, 
  normal_cols = 4611686018427389957, 
  new_total = 32224208, 
  new_normal = 32571766, 
  buffer = 32644769, 
  start = 32224213, 
  pointm = 12, 
  force_start = 32570294, 
  optional_new_start = 2053582435, 
[...]

etc.

bug#9904: 24.0.90; Crash in show_mouse_face

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Date: Sat, 29 Oct 2011 15:44:32 +0200
> 
> 
> Emacs segfaulted in show_mouse_face last week (revno 106154, I
> think). I have a core file.

What is this, an epidemic?

FWIW, I cannot find any change during the last 2 weeks that could
somehow be related.

> hlinfo->mouse_face_window is non-nil but contains garbage.

We could add a WINDOWP test where we currently use !NILP, before the
call to show_mouse_face in clear_mouse_face, but that would be a
band-aid.  Where could this garbled "window" come from? some GC or
memory-allocation snafu?

bug#9904: 24.0.90; Crash in show_mouse_face

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Emacs segfaulted in show_mouse_face last week (revno 106154, I
>> think). I have a core file.
>
> FWIW, I cannot find any change during the last 2 weeks that could
> somehow be related.
>
> Where could this garbled "window" come from? some GC or
> memory-allocation snafu?

Might the window assigned to dpyinfo->mouse_highlight->hlinfo have
gotten garbage collected?  Does the GC mark that slot?  I can't find the
place where it does so.

bug#9904: 24.0.90; Crash in show_mouse_face

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Johan Bockgård <bojohan@gnu.org>,  9904@debbugs.gnu.org
> Date: Sat, 29 Oct 2011 23:08:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Emacs segfaulted in show_mouse_face last week (revno 106154, I
> >> think). I have a core file.
> >
> > FWIW, I cannot find any change during the last 2 weeks that could
> > somehow be related.
> >
> > Where could this garbled "window" come from? some GC or
> > memory-allocation snafu?
> 
> Might the window assigned to dpyinfo->mouse_highlight->hlinfo have
> gotten garbage collected?  Does the GC mark that slot?  I can't find the
> place where it does so.

If the window was garbage collected, it was deleted first, right?  My
testing indicates that deleting a window calls clear_mouse_face
indirectly (because deleting a window from a frame runs
frame_up_to_date_hook for that frame, where we call
note_mouse_highlight.  So this ought to work OK, I think.

Maybe we should invalidate mouse_face_window inside
delete-window-internal, to make sure this window is no longer
referenced in dpyinfo->mouse_highlight->hlinfo?

bug#9904: 24.0.90; Crash in show_mouse_face

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe we should invalidate mouse_face_window inside
> delete-window-internal, to make sure this window is no longer
> referenced in dpyinfo->mouse_highlight->hlinfo?

Since no one has come up with a better suggestion, I implemented this.
Closing the bug; if the crash recurs, feel free to reopen.