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 linux

[Berndl, Klaus]

Hmm, very mysterious...
Jeff, Could you please test, if this bug occurs onyl with certain ECB-versions, so for exampe only with the new 2.22 and not with ECB 2.21 or vice versa or  if the bug occurs regardless which ECB-version is installed?

Does it only fail with current CVS Emacs or with the current release of Emacs 21 too. Have you tested it with XEmacs too? 

Have you tested it with a vanilla Emacs, means started by 
  emacs -q -no-site-file
and then just loading ECB and nxml-mode and nothing more?

Jeff, could you please answer to these questions? Thanks a lot!

Could you please file me a complete problem-report via `ecb-sumbit-problem-report' so i can see your configuration of ECB and some of the Emacs-internal-states?

Ciao,
Klaus

-----Original Message-----
From: Jens Lautenbacher
To: Kim F. Storm
Cc: Emacs-Devel; Berndl, Klaus
Sent: 10.03.2004 10:10
Subject: Re: repost: segfault on linux

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?

RE: repost: segfault on linux

[Jens Lautenbacher]

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

On Wed, 2004-03-10 at 10:23, Berndl, Klaus wrote:
> Hmm, very mysterious...
> Jeff, Could you please test, if this bug occurs onyl with certain ECB-versions, so for exampe only with the new 2.22 and not with ECB 2.21 or vice versa or  if the bug occurs regardless which ECB-version is installed?

Hmm, I strongly suspect that it doesn't depend on ECB... At least it
doesn't depend on wether cedet1-betac, cedet-CVS or the old seperate
semantic/speedbar/eieio stuff was used.

> Does it only fail with current CVS Emacs or with the current release of Emacs 21 too. Have you tested it with XEmacs too? 

Fails only with CVS Emacs, Emacs 21.3 works. XEmacs can't be tested, as
nxml doesn't work with it.

> Have you tested it with a vanilla Emacs, means started by 
>   emacs -q -no-site-file
> and then just loading ECB and nxml-mode and nothing more?

yes. also segfaults

> Jeff, could you please answer to these questions? Thanks a lot!

I answered, because I strongly suspect that you actually wanted to write
"Jens"... 

> Could you please file me a complete problem-report via
> `ecb-sumbit-problem-report' so i can see your configuration of ECB and
> some of the Emacs-internal-states?

I'll do, but not to the list...



[-- 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