bug#17411: 24.4.50; emacs_backtrace.txt

bug#17411: 24.4.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
012019c1
01201a32
010f43e6
01167502
011dd6fc
011dda0e
011dd9f4
011dd9f4
011dd9f4
011dd9f4
011dda06
011dd9f4
011dda06
011dd9f4
011dd9f4
011dda06
011dda2b
01167076
011670c7
0116509c
010f24e7
011c65d8
01186271
01185907
01185182
010f970e
0118262b
010f9b06
01185076
010f9b4a
010421cb
01041ed3
01045db5
01044c07
010faa21
01107e6e
010f8541
0118262b
010f7e76
01181bd8
010f7e2e
010f75c4
010f7780
010f5912
010010f9
75853386
76f09f6e
76f09f41




In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-04-29 on ODIEONE
Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

bug#17411: 24.4.50; emacs_backtrace.txt

[Juanma Barranquero]

??
??:0
w32_backtrace at w32fns.c:8476
emacs_abort at w32fns.c:8508
terminate_due_to_signal at emacs.c:382
die at alloc.c:6955
balance_an_interval at intervals.c:436
balance_intervals_internal at intervals.c:509
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:508
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:508
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:506
balance_intervals_internal at intervals.c:508
balance_intervals at intervals.c:517
sweep_buffers at alloc.c:6751
gc_sweep at alloc.c:6772
Fgarbage_collect at alloc.c:5680
maybe_gc at lisp.h:4527
exec_byte_code at bytecode.c:961
funcall_lambda at eval.c:3049
Ffuncall at eval.c:2864
call0 at eval.c:2599
safe_run_hooks_1 at keyboard.c:1872
internal_condition_case at eval.c:1354
safe_run_hook_funcall at keyboard.c:1927
run_hook_with_args at eval.c:2551
safe_run_hooks at keyboard.c:1944
update_menu_bar at xdisp.c:11733
prepare_menu_bars at xdisp.c:11634
redisplay_internal at xdisp.c:13437
redisplay at xdisp.c:13056
read_char at keyboard.c:2569
read_key_sequence at keyboard.c:9081
command_loop_1 at keyboard.c:1449
internal_condition_case at eval.c:1354
command_loop_2 at keyboard.c:1174
internal_catch at eval.c:1118
command_loop at keyboard.c:1153
recursive_edit_1 at keyboard.c:777
Frecursive_edit at keyboard.c:845
main at emacs.c:1654
?? at crt1.c:0
??
??:0
??
??:0
??
??:0

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 7 May 2014 17:20:13 +0200
> Cc: 17411@debbugs.gnu.org
> 
> w32_backtrace at w32fns.c:8476
> emacs_abort at w32fns.c:8508
> terminate_due_to_signal at emacs.c:382
> die at alloc.c:6955
> balance_an_interval at intervals.c:436
> balance_intervals_internal at intervals.c:509
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:508
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:508
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:506
> balance_intervals_internal at intervals.c:508
> balance_intervals at intervals.c:517
> sweep_buffers at alloc.c:6751
> gc_sweep at alloc.c:6772
> Fgarbage_collect at alloc.c:5680
> maybe_gc at lisp.h:4527

A duplicate of 17340.

bug#17411: 24.4.50; emacs_backtrace.txt

[Stefan Monnier]

>> balance_an_interval at intervals.c:436
>> balance_intervals_internal at intervals.c:509
>> balance_intervals_internal at intervals.c:506
> A duplicate of 17340.

Indeed.  Both seemed to fail the "eassert (LENGTH (i) > 0);" and right
in the middle of a tree.  I tried to add this assertion everywhere where the
length of an interval can be changed, so we should never bump into
a case like the above, because such a non-positive length should have
been caught by an assertion earlier.

Evidence shows that I missed some cases, tho.  I'd be interested to see
the stack trace before we enter GC (in case it's in the middle of some
interval manipulation, maybe?).  It might also be interesting to look at
`i' to see whether it's hopelessly messed up, or if it looks "incorrect
but sanish".


        Stefan

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Juanma Barranquero <lekktu@gmail.com>, 17411@debbugs.gnu.org
> Date: Sun, 11 May 2014 23:26:06 -0400
> 
> >> balance_an_interval at intervals.c:436
> >> balance_intervals_internal at intervals.c:509
> >> balance_intervals_internal at intervals.c:506
> > A duplicate of 17340.
> 
> Indeed.  Both seemed to fail the "eassert (LENGTH (i) > 0);" and right
> in the middle of a tree.  I tried to add this assertion everywhere where the
> length of an interval can be changed, so we should never bump into
> a case like the above, because such a non-positive length should have
> been caught by an assertion earlier.
> 
> Evidence shows that I missed some cases, tho.  I'd be interested to see
> the stack trace before we enter GC (in case it's in the middle of some
> interval manipulation, maybe?).

You mean, this one:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17411#8

> It might also be interesting to look at `i' to see whether it's
> hopelessly messed up, or if it looks "incorrect but sanish".

I was unable to convince Drew to run Emacs under GDB and leave the
crashed session running to allow us ask him to look around in the
crashed session.  So I think the only practical way of obtaining this
information is to add eassert's that will tell you which one is it.

bug#17411: 24.4.50; emacs_backtrace.txt

[Stefan Monnier]

>> Evidence shows that I missed some cases, tho.  I'd be interested to see
>> the stack trace before we enter GC (in case it's in the middle of some
>> interval manipulation, maybe?).
> You mean, this one:
>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17411#8

Ah, yes.
Sadly, this backtrace seems to say that the breakage doesn't come from
running GC in the middle of some interval manipulation.

> So I think the only practical way of obtaining this information is to
> add eassert's that will tell you which one is it.

But I don't know what to add where, at this point.


        Stefan

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: lekktu@gmail.com,  17411@debbugs.gnu.org
> Date: Mon, 12 May 2014 14:18:36 -0400
> 
> > So I think the only practical way of obtaining this information is to
> > add eassert's that will tell you which one is it.
> 
> But I don't know what to add where, at this point.

Maybe I misunderstood.  You said:

> It might also be interesting to look at `i' to see whether it's
> hopelessly messed up, or if it looks "incorrect but sanish".

So I thought about an eassert that will catch something "hopelessly
messed up", for example.

bug#17411: 24.4.50; emacs_backtrace.txt

[Stefan Monnier]

>> > So I think the only practical way of obtaining this information is to
>> > add eassert's that will tell you which one is it.
>> But I don't know what to add where, at this point.
> Maybe I misunderstood.  You said:
>> It might also be interesting to look at `i' to see whether it's
>> hopelessly messed up, or if it looks "incorrect but sanish".
> So I thought about an eassert that will catch something "hopelessly
> messed up", for example.

The "eassert (length (i) > 0)" does catch this case already.  We could
add another assert which is looser (i.e. one that would not be caught by
a "somewhat sane interval with a non-positive length"), but I'm not sure
how to formally define "hopelessly messed up".


        Stefan

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: lekktu@gmail.com, 17411@debbugs.gnu.org
> Date: Tue, 13 May 2014 15:32:13 -0400
> 
> The "eassert (length (i) > 0)" does catch this case already.  We could
> add another assert which is looser (i.e. one that would not be caught by
> a "somewhat sane interval with a non-positive length"), but I'm not sure
> how to formally define "hopelessly messed up".

You could display the values on your system in a debugger, and after
some time you should have a good idea what isn't messed up.

bug#17411: 24.4.50; emacs_backtrace.txt

[Stefan Monnier]

>> The "eassert (length (i) > 0)" does catch this case already.  We could
>> add another assert which is looser (i.e. one that would not be caught by
>> a "somewhat sane interval with a non-positive length"), but I'm not sure
>> how to formally define "hopelessly messed up".
> You could display the values on your system in a debugger, and after
> some time you should have a good idea what isn't messed up.

The problem is that it's not worth the trouble: knowing if the values are
sane or not isn't that interesting, so we'd really want to *see*
the values.  I'd "fprintf (stderr, ...)", but that wouldn't work under
w32 would it?


        Stefan

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: lekktu@gmail.com, 17411@debbugs.gnu.org
> Date: Tue, 13 May 2014 17:19:50 -0400
> 
> I'd "fprintf (stderr, ...)", but that wouldn't work under w32 would
> it?

Not if Emacs was invoked by clicking the desktop icon, which is the
usual way, no.

Perhaps we should add a feature to write arbitrary text into the
emacs_backtrace.txt file, when Emacs crashes.

bug#17411: 24.4.50; emacs_backtrace.txt

[Stefan Monnier]

> Perhaps we should add a feature to write arbitrary text into the
> emacs_backtrace.txt file, when Emacs crashes.

In any case, a much better option is to run the thing under a debugger.


        Stefan

bug#17411: 24.4.50; emacs_backtrace.txt

[Drew Adams]

> > I'd "fprintf (stderr, ...)", but that wouldn't work under w32 would
> > it?
> 
> Not if Emacs was invoked by clicking the desktop icon, which is the
> usual way, no.

FWIW, I invoke Emacs from a shortcut (on the Desktop) that points to
runemacs.exe.

bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 14 May 2014 07:38:42 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: lekktu@gmail.com, 17411@debbugs.gnu.org
> 
> > > I'd "fprintf (stderr, ...)", but that wouldn't work under w32 would
> > > it?
> > 
> > Not if Emacs was invoked by clicking the desktop icon, which is the
> > usual way, no.
> 
> FWIW, I invoke Emacs from a shortcut (on the Desktop) that points to
> runemacs.exe.

Yes, that's what I meant.

bug#17340: bug#17411: 24.4.50; emacs_backtrace.txt

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Cc: lekktu@gmail.com, 17411@debbugs.gnu.org
>> Date: Tue, 13 May 2014 17:19:50 -0400
>> 
>> I'd "fprintf (stderr, ...)", but that wouldn't work under w32 would
>> it?
>
> Not if Emacs was invoked by clicking the desktop icon, which is the
> usual way, no.
>
> Perhaps we should add a feature to write arbitrary text into the
> emacs_backtrace.txt file, when Emacs crashes.

It's unclear what the conclusion was in this report -- whether there was
something more to investigate or not...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17340: bug#17411: 24.4.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>,  17340@debbugs.gnu.org,  lekktu@gmail.com,  17411@debbugs.gnu.org
> Date: Sat, 26 Dec 2015 15:16:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> >> Cc: lekktu@gmail.com, 17411@debbugs.gnu.org
> >> Date: Tue, 13 May 2014 17:19:50 -0400
> >> 
> >> I'd "fprintf (stderr, ...)", but that wouldn't work under w32 would
> >> it?
> >
> > Not if Emacs was invoked by clicking the desktop icon, which is the
> > usual way, no.
> >
> > Perhaps we should add a feature to write arbitrary text into the
> > emacs_backtrace.txt file, when Emacs crashes.
> 
> It's unclear what the conclusion was in this report -- whether there was
> something more to investigate or not...

I think it should be closed.  These problems didn't happen in a long
while.