repost: segfault on linux

repost: segfault on linux

[Jens Lautenbacher]

[this didn't get through?]

Hi, 

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)

Program received signal SIGSEGV, Segmentation fault.
0x00b9c98f in msort_with_tmp () from /lib/tls/libc.so.6
(gdb) where
#0  0x00b9c98f in msort_with_tmp () from /lib/tls/libc.so.6
#1  0x00b9c9f0 in msort_with_tmp () from /lib/tls/libc.so.6
#2  0x00b9ccb8 in qsort () from /lib/tls/libc.so.6
#3  0x0812aabe in sort_overlays (overlay_vec=0xbf600110, noverlays=2,
w=0x0) at buffer.c:2873
#4  0x081a7e69 in get_char_property_and_overlay (position=1,
prop=675417024, object=-1976777440,
    overlay=0x0) at textprop.c:664
#5  0x081a7f8a in Fget_char_property (position=1, prop=675417024,
object=-1976777440)
    at textprop.c:704
#6  0x0809468d in handle_display_prop (it=0xbff285f0) at xdisp.c:3286
#7  0x08093870 in handle_stop (it=0xbff285f0) at xdisp.c:2567
#8  0x0809773d in next_element_from_buffer (it=0xbff285f0) at
xdisp.c:5439
#9  0x08096b80 in get_next_display_element (it=0xbff285f0) at
xdisp.c:4791
#10 0x08096b80 in get_next_display_element (it=0xbff285f0) at
xdisp.c:4791
#11 0x08096b80 in get_next_display_element (it=0xbff285f0) at
xdisp.c:4791
#12 0x08096b80 in get_next_display_element (it=0xbff285f0) at
xdisp.c:4791

(last line repeated)

Re: repost: segfault on linux

[Kim F. Storm]

Jens Lautenbacher <jtl@schlund.de> writes:

> [this didn't get through?]

It did -- eventually...

> 
> Hi, 
> 
> 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.

> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00b9c98f in msort_with_tmp () from /lib/tls/libc.so.6
> (gdb) where
> #0  0x00b9c98f in msort_with_tmp () from /lib/tls/libc.so.6
> #1  0x00b9c9f0 in msort_with_tmp () from /lib/tls/libc.so.6
> #2  0x00b9ccb8 in qsort () from /lib/tls/libc.so.6
> #3  0x0812aabe in sort_overlays (overlay_vec=0xbf600110, noverlays=2,
> w=0x0) at buffer.c:2873
> #4  0x081a7e69 in get_char_property_and_overlay (position=1,
> prop=675417024, object=-1976777440,
>     overlay=0x0) at textprop.c:664
> #5  0x081a7f8a in Fget_char_property (position=1, prop=675417024,
> object=-1976777440)
>     at textprop.c:704
> #6  0x0809468d in handle_display_prop (it=0xbff285f0) at xdisp.c:3286
> #7  0x08093870 in handle_stop (it=0xbff285f0) at xdisp.c:2567
> #8  0x0809773d in next_element_from_buffer (it=0xbff285f0) at
> xdisp.c:5439
> #9  0x08096b80 in get_next_display_element (it=0xbff285f0) at
> xdisp.c:4791
> #10 0x08096b80 in get_next_display_element (it=0xbff285f0) at
> xdisp.c:4791
> #11 0x08096b80 in get_next_display_element (it=0xbff285f0) at
> xdisp.c:4791
> #12 0x08096b80 in get_next_display_element (it=0xbff285f0) at
> xdisp.c:4791
> 
> (last line repeated)
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: repost: segfault on linux

[Jens Lautenbacher]

[-- Attachment #1.1: Type: text/plain, Size: 3241 bytes --]

On Mon, 2004-03-08 at 18:34, Kim F. Storm wrote:
> Jens Lautenbacher <jtl@schlund.de> 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?



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: repost: segfault on GNU/Linux

[Richard Stallman]

    Program received signal SIGSEGV, Segmentation fault.
    0x08203e7c in find_interval (tree=3D0x9fc13cc, position=3D1) at intervals.c=
    :652
    652         tree =3D balance_possible_root_interval (tree);
    (gdb) l

That pretty clearly suggests that the interval structure (text
properties) contains invalid data.  That is very strange, since the
previous but seems to concern overlays.  Overlays and text properties are
different data and are handled by different code.

Can you come up with a single reproducible case that always fails
in the same way?

    Fails only with CVS Emacs, Emacs 21.3 works.

This means we can't expect the bug to disappear automatically
with the next release.

						 XEmacs can't be tested,

Even if it could be tested, the results would not teach us anything
about this bug.  XEmacs does not have either intervals or overlays.

All my experience suggests that the approach of trying various cases
to look for a pattern of where failures occur is not useful, because
it generally does not lead anywhere.

The only way to find such bugs is by studying the code in detail,
finding what's invalid in the data, and tracing the causality back
step by step.