emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

22.0.50 SEGFAULT


From: JD Smith
Subject: 22.0.50 SEGFAULT
Date: Thu, 14 Jul 2005 19:28:54 -0700
User-agent: Pan/0.14.2.91 (As She Crawled Across the Table)

I'm still getting SEGFAULTS in the most recent CVS build, relating to
increment_row_positions.  I had previously reported this was fixed in
22.0.50, but had not tested adequately.  It is an intermittent
SEGFAULT, usually triggered by a key comand that causes window
redisplay.  This is:

GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2005-07-14 on turtle.as.arizona.edu

(gdb) run
Starting program: /usr/local/bin/emacs -geometry 80x40+0+0
Detaching after fork from child process 24951.

Program received signal SIGSEGV, Segmentation fault.
0x08050c4f in increment_row_positions (row=0x8b865c8, delta=-1, delta_bytes=4)
    at dispnew.c:1190
1190          if (BUFFERP (row->glyphs[area][i].object)
(gdb) bt
#0  0x08050c4f in increment_row_positions (row=0x8b865c8, delta=-1,
    delta_bytes=4) at dispnew.c:1190
#1  0x08050cce in increment_matrix_positions (matrix=0x8532e40, start=5,
    end=1176, delta=-1, delta_bytes=-1) at dispnew.c:929
#2  0x0806e3aa in try_window_id (w=0x851e960) at xdisp.c:14096
#3  0x08073e21 in redisplay_window (window=139585892, just_this_one_p=1)
    at xdisp.c:12346
#4  0x08075c89 in redisplay_window_1 (window=139585892) at xdisp.c:11053
#5  0x0813ae6c in internal_condition_case_1 (
    bfun=0x8075c5c <redisplay_window_1>, arg=139585892, handlers=137332933,
    hfun=0x806b398 <redisplay_window_error>) at eval.c:1492
#6  0x08076f20 in redisplay_internal (preserve_echo_area=4) at xdisp.c:10652
#7  0x080e6755 in read_char (commandflag=1, nmaps=2, maps=0xbfffed30,
    prev_event=137306129, used_mouse_menu=0xbfffed78) at keyboard.c:2540
#8  0x080e92da in read_key_sequence (keybuf=0xbfffee90, bufsize=30,
    prompt=137306129, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8817
#9  0x080eabe5 in command_loop_1 () at keyboard.c:1528
#10 0x0813b142 in internal_condition_case (bfun=0x80eaa4c <command_loop_1>,
    handlers=137367121, hfun=0x80e4a90 <cmd_error>) at eval.c:1451
#11 0x080df45e in command_loop_2 () at keyboard.c:1318
#12 0x0813b051 in internal_catch (tag=4, func=0x80df440 <command_loop_2>,
    arg=137306129) at eval.c:1210
---Type <return> to continue, or q <return> to quit---
#13 0x080df26d in command_loop () at keyboard.c:1297
#14 0x080df307 in recursive_edit_1 () at keyboard.c:990
#15 0x080df402 in Frecursive_edit () at keyboard.c:1051
#16 0x080de789 in main (argc=3, argv=0xbffff494) at emacs.c:1782

When expanding out all the macros from BUFFERP and cleaning up, the
offending code looks like:

if (((((enum Lisp_Type) (((unsigned int) ((row->glyphs[area][i].object))) & 
                         ((((int) 1) << 3) - 1))) == Lisp_Vectorlike) && 
     (((((void) 0,(struct Lisp_Vector *)
         ((int) ((row->glyphs[area][i].object) & 
                 ~((((int) 1) << 3) - 1))))->size & 
        (((((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1))) >> 1) & 
          ~((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1)))) | 
         (PVEC_BUFFER)))) == 
      (((((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1))) >> 1) & 
        ~((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1)))) | (PVEC_BUFFER))))
    && row->glyphs[area][i].charpos > 0)
     row->glyphs[area][i].charpos += delta;

When I examine row->glyphs[area][i], I find:

(gdb) print row->glyphs[area][i]
$10 = {
  charpos = 1,
  object = 137601675,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 13,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
   ch = 102,
    cmp_id = 102,
    img_id = 102,
    stretch = {
      height = 102,
      ascent = 0
    },
    val = 102
  }
}

which looks completely valid.  The only problem I find when poking
around with GDB is:

(gdb) p (int)PVEC_BUFFER
No symbol "PVEC_BUFFER" in current context.

In contrast to the other enum type:

(gdb) p (int)Lisp_Vectorlike
$74 = 4

That could well be more of a debugging symbol issue than anything
real.  Does this provide enough clues for anyone?  Any suggestions on
what else I should try when I trigger the SEGFAULT again?

Thanks,

JD






reply via email to

[Prev in Thread] Current Thread [Next in Thread]