Re: repost: segfault on linux

[Jens Lautenbacher]

On Mon, 2004-03-08 at 18:34, Kim F. Storm wrote:
> Jens Lautenbacher <address@hidden> writes:
> > When trying to use James Clarks nxml mode (nxml-mode-20031031) with
> > syntax highlighting turned on, current CVS emacs segfaults with the
> > following stacktrace. please tell me if I should provide more
> > information (this is CVS from today, on Fedora Core I, emacs built with
> > gtk enabled)
> 
> As always, it would be helpful if you tried to give a more precise
> recipe for reproducing this -- and also tried to narrow down exactly
> what data causes this crash to occur.
> 
> Also have a a look at etc/DEBUG for advise on trying to debug
> this a little further yourself.

OK, I will not be of much help when it comes down to the C side of
things, but I try to explain better what leads to the segfault.

First of all, it only happens when the syntax highlighting is on in
nxml. Second, it only happens when ECB is also running, and the xml file
is loaded by clicking on a xml file name in ECB's history or directory
buffer. It does NOT happen when ECB runs and I simply find-file a xml
file. So it may be the question if it's nxml or ECB's fault here, but on
the other hand I suppose a segfault is not an acceptable response :-)

I tried to look at the debugger output some more (with CVS emacs as of
today, compiled without optimization and only "-g"), and the stacktrace
looks a bit different from what I saw the last time

Program received signal SIGSEGV, Segmentation fault.
0x08203e7c in find_interval (tree=0x9fc13cc, position=1) at intervals.c:652
652         tree = balance_possible_root_interval (tree);
(gdb) l
647
648       if (relative_position > TOTAL_LENGTH (tree))
649         abort ();                   /* Paranoia */
650
651       if (!handling_signal)
652         tree = balance_possible_root_interval (tree);
653
654       while (1)
655         {
656           if (relative_position < LEFT_TOTAL_LENGTH (tree))

(gdb) where
#0  0x08203e7c in find_interval (tree=0x9fc13cc, position=1) at intervals.c:652
#1  0x08207ead in validate_interval_range (object=-1982984752, 
begin=0xbf6000b0, end=0xbf6000b0, force=0)
    at textprop.c:181
#2  0x08208ab4 in Ftext_properties_at (position=1, object=-1982984752) at 
textprop.c:585
#3  0x08208b83 in Fget_text_property (position=1, prop=675635440, 
object=-1982984752) at textprop.c:606
#4  0x081054f3 in face_at_buffer_position (w=0x9dbb6d8, pos=1, region_beg=-1, 
region_end=-1, endptr=0xbf600200,
    limit=101, mouse=0) at xfaces.c:7313
#5  0x0809a5fc in handle_face_prop (it=0xbfecc670) at xdisp.c:2841
#6  0x08099f67 in handle_stop (it=0xbfecc670) at xdisp.c:2567
#7  0x0809f96e in next_element_from_buffer (it=0xbfecc670) at xdisp.c:5439
#8  0x0809e641 in get_next_display_element (it=0xbfecc670) at xdisp.c:4791

(gdb) p *tree
$2 = {total_length = 32, position = 14, left = 0x9fc13b0, right = 0x9fc13e8, up 
= {interval = 0x89ce0dd0,
    obj = -1982984752}, up_obj = 1, gcmarkbit = 0, write_protect = 0, visible = 
0, front_sticky = 0, rear_sticky = 0,
  plist = 675635056}


Thank god I'm a java guy, so I don't know much about C and C debugging anymore, 
but doesn't the tree->up->obj look strange?

signature.asc
Description: This is a digitally signed message part