Emacs trunk crash

Emacs trunk crash

[Fabrice Popineau]

Hi,

Just got a crash with emacs/trunk/w64. The emacs used to debug this has been 
compiled unoptimized.
I wanted to let the mailing list know in case there is something to fix here.
The backtrace is:

(gdb) where
#0  0x000000040024ba41 in substitute_object_recurse (object=107071061, 
placeholder=8607363, subtree=3)
    at ../../emacs/src/lread.c:3306
#1  0x000000040024b9ae in substitute_object_recurse (object=107071061, 
placeholder=8607363,
    subtree=107071061) at ../../emacs/src/lread.c:3299
#2  0x000000040024b777 in substitute_object_in_subtree (object=107071061, 
placeholder=8607363)
    at ../../emacs/src/lread.c:3234
#3  0x000000040024a58e in read1 (readcharfun=197175989, pch=0x8358bc, 
first_in_list=false)
    at ../../emacs/src/lread.c:2847

If i look at the #1 frame, where subtree still has a meaningful value :

(gdb) p subtree
$7 = 107071061
(gdb) xtype subtree
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) xsubchartable subtree
$8 = (struct Lisp_Sub_Char_Table *) 0x661c650
Depth: 3, Min char: 0 (0x0)
(gdb) p AREF(subtree, 0)
$9 = 3
(gdb)

This is the consequence of an unattented shutdown of my machine with a long 
emacs session running. I'm not sure I'll be able to reproduce it at all. But for 
the time being, I'm unable to restart my session. Emacs is crashing while 
restoring one of the files of my session.

Regards,

Fabrice

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 20 Mar 2015 23:21:41 +0000 (UTC)
> 
> Just got a crash with emacs/trunk/w64. The emacs used to debug this has been 
> compiled unoptimized.
> I wanted to let the mailing list know in case there is something to fix here.
> The backtrace is:
> 
> (gdb) where
> #0  0x000000040024ba41 in substitute_object_recurse (object=107071061, 
> placeholder=8607363, subtree=3)
>     at ../../emacs/src/lread.c:3306
> #1  0x000000040024b9ae in substitute_object_recurse (object=107071061, 
> placeholder=8607363,
>     subtree=107071061) at ../../emacs/src/lread.c:3299
> #2  0x000000040024b777 in substitute_object_in_subtree (object=107071061, 
> placeholder=8607363)
>     at ../../emacs/src/lread.c:3234
> #3  0x000000040024a58e in read1 (readcharfun=197175989, pch=0x8358bc, 
> first_in_list=false)
>     at ../../emacs/src/lread.c:2847

A fuller backtrace, including "xbacktrace" for the Lisp part, might
show some useful information.

Also, can you show the Lisp object being read here?

> This is the consequence of an unattented shutdown of my machine with a long 
> emacs session running. I'm not sure I'll be able to reproduce it at all. But for 
> the time being, I'm unable to restart my session. Emacs is crashing while 
> restoring one of the files of my session.

What kind of file is the file that causes the crash?  is it a Lisp
file?

Re: Emacs trunk crash

[Fabrice Popineau]

Eli Zaretskii <eliz <at> gnu.org> writes:
 
> A fuller backtrace, including "xbacktrace" for the Lisp part, might
> show some useful information.

Luckily, the crash is constant and still happens by just restoring the 
.emacs.desktop file. So I may be able to reproduce it.

I have put the full backtrace at the end of the message.

For the xbacktrace:

(gdb) xbacktrace
"read" (0x838fa8)
0xc2c77f0 PVEC_COMPILED
"funcall" (0x8394f0)
0xc2c5a30 PVEC_COMPILED
"funcall" (0x839d10)
"undo-tree-load-history" (0x83a480)
"undo-tree-load-history-hook" (0x83aad8)
"run-hooks" (0x83ac48)
"after-find-file" (0x83b1d8)
"find-file-noselect-1" (0x83b768)
"find-file-noselect" (0x83bce8)
"desktop-restore-file-buffer" (0x83c2e0)
"desktop-create-buffer" (0x83c760)
"eval-buffer" (0x83ccd0)
"load-with-code-conversion" (0x83d228)
"load" (0x83d9f8)
"desktop-read" (0x83de80)
"if" (0x83e1f8)
"progn" (0x83e3c8)
"if" (0x83e598)
"desktop-settings-setup" (0x83e948)
"run-hooks" (0x83ea90)
"command-line" (0x83f058)
---Type <return> to continue, or q <return> to quit---
"normal-top-level" (0x83f4f0)

So it happens while restoring the undo-tree history.

At frame #1 :
(gdb) p object
$8 = 167822037
(gdb) xtype
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) p object
$6 = 167822037
(gdb) xsubchartable
$7 = (struct Lisp_Sub_Char_Table *) 0xa00c2d0
Depth: 3, Min char: 0 (0x0)
 
> Also, can you show the Lisp object being read here?

I take any instruction to dig any further.
I am a bit stuck on how to print even the lisp form that is evaluated.
 
> What kind of file is the file that causes the crash?  is it a Lisp
> file?

It seems to be one of the files to be restored, yes. 

There is lots of bytecode which is executed during the backtrace.
I don't know much about exploring those frames.

Fabrice

#0  0x000000040024ba41 in substitute_object_recurse (object=167822037,
    placeholder=8607363, subtree=3) at ../../emacs/src/lread.c:3306
#1  0x000000040024b9ae in substitute_object_recurse (object=167822037,
    placeholder=8607363, subtree=167822037) at ../../emacs/src/lread.c:3299
#2  0x000000040024b777 in substitute_object_in_subtree (object=167822037,
    placeholder=8607363) at ../../emacs/src/lread.c:3234
#3  0x000000040024a58e in read1 (readcharfun=196995557, pch=0x8358bc,
    first_in_list=false) at ../../emacs/src/lread.c:2847
#4  0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#5  0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#6  0x000000040024954d in read1 (readcharfun=196995557, pch=0x835d0c,
    first_in_list=false) at ../../emacs/src/lread.c:2566
#7  0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#8  0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#9  0x000000040024954d in read1 (readcharfun=196995557, pch=0x83615c,
    first_in_list=false) at ../../emacs/src/lread.c:2566
#10 0x0000000400248609 in read0 (readcharfun=196995557)
    at ../../emacs/src/lread.c:2135
#11 0x000000040024a56e in read1 (readcharfun=196995557, pch=0x83644c,
    first_in_list=false) at ../../emacs/src/lread.c:2844
#12 0x000000040024c5b5 in read_list (flag=false, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#13 0x0000000400248f7c in read1 (readcharfun=196995557, pch=0x83685c,
    first_in_list=false) at ../../emacs/src/lread.c:2473
#14 0x0000000400249e8b in read1 (readcharfun=196995557, pch=0x836abc,
    first_in_list=true) at ../../emacs/src/lread.c:2684
#15 0x000000040024c5b5 in read_list (flag=false, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#16 0x0000000400248f7c in read1 (readcharfun=196995557, pch=0x836e7c,
    first_in_list=false) at ../../emacs/src/lread.c:2473
#17 0x000000040024c5b5 in read_list (flag=false, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#18 0x0000000400248f7c in read1 (readcharfun=196995557, pch=0x83723c,
    first_in_list=false) at ../../emacs/src/lread.c:2473
#19 0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#20 0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#21 0x0000000400248f93 in read1 (readcharfun=196995557, pch=0x83768c,
    first_in_list=false) at ../../emacs/src/lread.c:2476
#22 0x0000000400248609 in read0 (readcharfun=196995557)
    at ../../emacs/src/lread.c:2135
#23 0x000000040024a56e in read1 (readcharfun=196995557, pch=0x83797c,
    first_in_list=true) at ../../emacs/src/lread.c:2844
#24 0x000000040024c5b5 in read_list (flag=false, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#25 0x0000000400248f7c in read1 (readcharfun=196995557, pch=0x837d3c,
    first_in_list=false) at ../../emacs/src/lread.c:2473
#26 0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#27 0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#28 0x0000000400248f93 in read1 (readcharfun=196995557, pch=0x83818c,
    first_in_list=true) at ../../emacs/src/lread.c:2476
#29 0x000000040024c5b5 in read_list (flag=false, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#30 0x0000000400248f7c in read1 (readcharfun=196995557, pch=0x83854c,
    first_in_list=false) at ../../emacs/src/lread.c:2473
#31 0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#32 0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#33 0x0000000400248f93 in read1 (readcharfun=196995557, pch=0x83899c,
    first_in_list=false) at ../../emacs/src/lread.c:2476
#34 0x000000040024c5b5 in read_list (flag=true, readcharfun=196995557)
    at ../../emacs/src/lread.c:3585
#35 0x000000040024c149 in read_vector (readcharfun=196995557,
    bytecodeflag=false) at ../../emacs/src/lread.c:3493
#36 0x0000000400248f93 in read1 (readcharfun=196995557, pch=0x838dec,
    first_in_list=false) at ../../emacs/src/lread.c:2476
#37 0x0000000400248609 in read0 (readcharfun=196995557)
    at ../../emacs/src/lread.c:2135
#38 0x0000000400248551 in read_internal_start (stream=196995557, start=0,
    end=0) at ../../emacs/src/lread.c:2108
#39 0x000000040024831d in Fread (stream=196995557)
    at ../../emacs/src/lread.c:2055
#40 0x00000004002106e2 in Ffuncall (nargs=2, args=0x838fa0)
    at ../../emacs/src/eval.c:2718
#41 0x000000040026437a in exec_byte_code (bytestr=148225940, vector=204237565,
    maxdepth=14, args_template=2, nargs=0, args=0x8394f8)
    at ../../emacs/src/bytecode.c:919
#42 0x00000004002111be in funcall_lambda (fun=204240885, nargs=0,
    arg_vector=0x8394f8) at ../../emacs/src/eval.c:2885
#43 0x0000000400210a5e in Ffuncall (nargs=1, args=0x8394f0)
    at ../../emacs/src/eval.c:2767
#44 0x000000040020ebfa in eval_sub (form=205182435)
    at ../../emacs/src/eval.c:2154
#45 0x000000040020c3a6 in internal_lisp_condition_case (var=-17058665872,
    bodyform=205182435, handlers=205182531) at ../../emacs/src/eval.c:1317
#46 0x00000004002658c6 in exec_byte_code (bytestr=148224820, vector=204236645,
    maxdepth=66, args_template=2, nargs=0, args=0x839d18)
    at ../../emacs/src/bytecode.c:1162
#47 0x00000004002111be in funcall_lambda (fun=204233269, nargs=0,
    arg_vector=0x839d18) at ../../emacs/src/eval.c:2885
#48 0x0000000400210a5e in Ffuncall (nargs=1, args=0x839d10)
    at ../../emacs/src/eval.c:2767
#49 0x000000040020ebfa in eval_sub (form=205183939)
    at ../../emacs/src/eval.c:2154
#50 0x000000040020b833 in internal_catch (tag=-17058665984,
    func=0x40020e54c <eval_sub>, arg=205183939) at ../../emacs/src/eval.c:1108
#51 0x00000004002654e5 in exec_byte_code (bytestr=148224500, vector=148206389,
    maxdepth=50, args_template=2050, nargs=2, args=0x83a490)
    at ../../emacs/src/bytecode.c:1100
#52 0x00000004002111be in funcall_lambda (fun=148206525, nargs=2,
    arg_vector=0x83a480) at ../../emacs/src/eval.c:2885
#53 0x0000000400210a5e in Ffuncall (nargs=3, args=0x83a478)
    at ../../emacs/src/eval.c:2767
#54 0x000000040026437a in exec_byte_code (bytestr=148227796, vector=148206685,
    maxdepth=14, args_template=2, nargs=0, args=0x83aad8)
    at ../../emacs/src/bytecode.c:919
#55 0x00000004002111be in funcall_lambda (fun=148206749, nargs=0,
    arg_vector=0x83aad8) at ../../emacs/src/eval.c:2885
#56 0x0000000400210a5e in Ffuncall (nargs=1, args=0x83aad0)
    at ../../emacs/src/eval.c:2767
#57 0x000000040020f781 in funcall_nil (nargs=1, args=0x83aad0)
    at ../../emacs/src/eval.c:2348
#58 0x000000040020fc78 in run_hook_with_args (nargs=1, args=0x83aad0,
    funcall=0x40020f761 <funcall_nil>) at ../../emacs/src/eval.c:2522
#59 0x000000040020f811 in Frun_hook_with_args (nargs=1, args=0x83aad0)
    at ../../emacs/src/eval.c:2390
#60 0x000000040020fe19 in run_hook (hook=-17058976600)
    at ../../emacs/src/eval.c:2543
#61 0x000000040020f7c9 in Frun_hooks (nargs=1, args=0x83ac48)
    at ../../emacs/src/eval.c:2372
#62 0x0000000400210547 in Ffuncall (nargs=2, args=0x83ac40)
    at ../../emacs/src/eval.c:2698
#63 0x000000040026437a in exec_byte_code (bytestr=17183703564,
    vector=17183703597, maxdepth=42, args_template=5122, nargs=2,
    args=0x83b1e8) at ../../emacs/src/bytecode.c:919
#64 0x00000004002111be in funcall_lambda (fun=17183703517, nargs=2,
    arg_vector=0x83b1d8) at ../../emacs/src/eval.c:2885
#65 0x0000000400210a5e in Ffuncall (nargs=3, args=0x83b1d0)
    at ../../emacs/src/eval.c:2767
#66 0x000000040026437a in exec_byte_code (bytestr=17183701764,
    vector=17183701797, maxdepth=46, args_template=6170, nargs=6,
    args=0x83b798) at ../../emacs/src/bytecode.c:919
#67 0x00000004002111be in funcall_lambda (fun=17183701717, nargs=6,
    arg_vector=0x83b768) at ../../emacs/src/eval.c:2885
#68 0x0000000400210a5e in Ffuncall (nargs=7, args=0x83b760)
    at ../../emacs/src/eval.c:2767
#69 0x000000040026437a in exec_byte_code (bytestr=17183700412,
    vector=17183700445, maxdepth=70, args_template=4102, nargs=1,
    args=0x83bcf0) at ../../emacs/src/bytecode.c:919
#70 0x00000004002111be in funcall_lambda (fun=17183700365, nargs=1,
    arg_vector=0x83bce8) at ../../emacs/src/eval.c:2885
#71 0x0000000400210a5e in Ffuncall (nargs=2, args=0x83bce0)
    at ../../emacs/src/eval.c:2767
#72 0x000000040026437a in exec_byte_code (bytestr=102121668, vector=199249157,
    maxdepth=30, args_template=3086, nargs=3, args=0x83c2f8)
    at ../../emacs/src/bytecode.c:919
#73 0x00000004002111be in funcall_lambda (fun=199249325, nargs=3,
    arg_vector=0x83c2e0) at ../../emacs/src/eval.c:2885
#74 0x0000000400210a5e in Ffuncall (nargs=4, args=0x83c2d8)
    at ../../emacs/src/eval.c:2767
#75 0x000000040026437a in exec_byte_code (bytestr=102120516, vector=199249421,
    maxdepth=126, args_template=11814, nargs=11, args=0x83c7b8)
    at ../../emacs/src/bytecode.c:919
#76 0x00000004002111be in funcall_lambda (fun=199249765, nargs=11,
    arg_vector=0x83c760) at ../../emacs/src/eval.c:2885
#77 0x0000000400210e33 in apply_lambda (fun=199249765, args=157861555,
    count=43) at ../../emacs/src/eval.c:2826
#78 0x000000040020ef3a in eval_sub (form=157861539)
    at ../../emacs/src/eval.c:2226
#79 0x000000040024754d in readevalloop_eager_expand_eval (val=157861539,
    macroexpand=-18721912) at ../../emacs/src/lread.c:1756
#80 0x0000000400247d38 in readevalloop (readcharfun=156354037, stream=0x0,
    sourcename=102731012, printflag=false, unibyte=0, readfun=0, start=0,
    end=0) at ../../emacs/src/lread.c:1927
#81 0x00000004002480ef in Feval_buffer (buffer=156354037, printflag=0,
    filename=102701476, unibyte=0, do_allow_print=56840)
    at ../../emacs/src/lread.c:1990
#82 0x0000000400210838 in Ffuncall (nargs=6, args=0x83ccc8)
    at ../../emacs/src/eval.c:2734
#83 0x000000040026437a in exec_byte_code (bytestr=17183484964,
    vector=17183484997, maxdepth=26, args_template=0, nargs=0, args=0x0)
    at ../../emacs/src/bytecode.c:919
#84 0x0000000400211676 in funcall_lambda (fun=17183484837, nargs=4,
    arg_vector=0x400372c45 <pure+190725>) at ../../emacs/src/eval.c:2951
#85 0x0000000400210a5e in Ffuncall (nargs=5, args=0x83d220)
    at ../../emacs/src/eval.c:2767
#86 0x0000000400210017 in call4 (fn=-18449752, arg1=102701476, arg2=102701476,
    arg3=56840, arg4=56840) at ../../emacs/src/eval.c:2598
#87 0x0000000400245c74 in Fload (file=102701572, noerror=56840,
    nomessage=56840, nosuffix=56840, must_suffix=0)
    at ../../emacs/src/lread.c:1268
#88 0x0000000400210838 in Ffuncall (nargs=5, args=0x83d9f0)
    at ../../emacs/src/eval.c:2734
#89 0x000000040026437a in exec_byte_code (bytestr=103369012, vector=199244789,
    maxdepth=66, args_template=1026, nargs=1, args=0x83de88)
    at ../../emacs/src/bytecode.c:919
#90 0x00000004002111be in funcall_lambda (fun=199245357, nargs=1,
    arg_vector=0x83de80) at ../../emacs/src/eval.c:2885
#91 0x0000000400210e33 in apply_lambda (fun=199245357, args=129863635,
    count=11) at ../../emacs/src/eval.c:2826
#92 0x000000040020ef3a in eval_sub (form=129863619)
    at ../../emacs/src/eval.c:2226
#93 0x0000000400208f12 in Fif (args=129863603) at ../../emacs/src/eval.c:396
#94 0x000000040020e9dc in eval_sub (form=129863539)
    at ../../emacs/src/eval.c:2131
#95 0x00000004002091eb in Fprogn (body=129862179) at ../../emacs/src/eval.c:445
#96 0x000000040020e9dc in eval_sub (form=129861187)
    at ../../emacs/src/eval.c:2131
#97 0x0000000400208f12 in Fif (args=129861427) at ../../emacs/src/eval.c:396
#98 0x000000040020e9dc in eval_sub (form=129861411)
    at ../../emacs/src/eval.c:2131
#99 0x00000004002091eb in Fprogn (body=129861523) at ../../emacs/src/eval.c:445
#100 0x00000004002115d9 in funcall_lambda (fun=129861459, nargs=0,
    arg_vector=0x83e948) at ../../emacs/src/eval.c:2944
#101 0x0000000400210b95 in Ffuncall (nargs=1, args=0x83e940)
    at ../../emacs/src/eval.c:2779
#102 0x000000040020f781 in funcall_nil (nargs=1, args=0x83e940)
    at ../../emacs/src/eval.c:2348
#103 0x000000040020fd6e in run_hook_with_args (nargs=1, args=0x83e940,
    funcall=0x40020f761 <funcall_nil>) at ../../emacs/src/eval.c:2529
#104 0x000000040020f811 in Frun_hook_with_args (nargs=1, args=0x83e940)
    at ../../emacs/src/eval.c:2390
#105 0x000000040020fe19 in run_hook (hook=-17074429296)
    at ../../emacs/src/eval.c:2543
#106 0x000000040020f7c9 in Frun_hooks (nargs=1, args=0x83ea90)
    at ../../emacs/src/eval.c:2372
#107 0x0000000400210547 in Ffuncall (nargs=2, args=0x83ea88)
    at ../../emacs/src/eval.c:2698
#108 0x000000040026437a in exec_byte_code (bytestr=17184453268,
    vector=17184453301, maxdepth=74, args_template=2, nargs=0, args=0x83f058)
    at ../../emacs/src/bytecode.c:919
#109 0x00000004002111be in funcall_lambda (fun=17184453221, nargs=0,
    arg_vector=0x83f058) at ../../emacs/src/eval.c:2885
#110 0x0000000400210a5e in Ffuncall (nargs=1, args=0x83f050)
    at ../../emacs/src/eval.c:2767
#111 0x000000040026437a in exec_byte_code (bytestr=17184450252,
    vector=17184450285, maxdepth=50, args_template=2, nargs=0, args=0x83f4f0)
    at ../../emacs/src/bytecode.c:919
#112 0x00000004002111be in funcall_lambda (fun=17184450205, nargs=0,
    arg_vector=0x83f4f0) at ../../emacs/src/eval.c:2885
#113 0x0000000400210e33 in apply_lambda (fun=17184450205, args=0, count=3)
    at ../../emacs/src/eval.c:2826
#114 0x000000040020ef3a in eval_sub (form=17189337475)
    at ../../emacs/src/eval.c:2226
#115 0x000000040020e2e3 in Feval (form=17189337475, lexical=0)
    at ../../emacs/src/eval.c:1996
#116 0x000000040015277d in top_level_2 () at ../../emacs/src/keyboard.c:1148
#117 0x000000040020c53f in internal_condition_case (
    bfun=0x400152756 <top_level_2>, handlers=23184,
    hfun=0x4001520c9 <cmd_error>) at ../../emacs/src/eval.c:1348
#118 0x00000004001527c9 in top_level_1 (ignore=0)
    at ../../emacs/src/keyboard.c:1156
#119 0x000000040020b833 in internal_catch (tag=58968,
    func=0x400152782 <top_level_1>, arg=0) at ../../emacs/src/eval.c:1108
#120 0x000000040015269f in command_loop () at ../../emacs/src/keyboard.c:1117
#121 0x0000000400151b10 in recursive_edit_1 ()
    at ../../emacs/src/keyboard.c:728
#122 0x0000000400151d51 in Frecursive_edit () at ../../emacs/src/keyboard.c:799
#123 0x000000040014f392 in main (argc=1, argv=0xd16ac0)
    at ../../emacs/src/emacs.c:1626

Lisp Backtrace:
"read" (0x838fa8)
0xc2c77f0 PVEC_COMPILED
"funcall" (0x8394f0)
0xc2c5a30 PVEC_COMPILED
"funcall" (0x839d10)
"undo-tree-load-history" (0x83a480)
"undo-tree-load-history-hook" (0x83aad8)
"run-hooks" (0x83ac48)
"after-find-file" (0x83b1d8)
"find-file-noselect-1" (0x83b768)
"find-file-noselect" (0x83bce8)
"desktop-restore-file-buffer" (0x83c2e0)
"desktop-create-buffer" (0x83c760)
"eval-buffer" (0x83ccd0)
"load-with-code-conversion" (0x83d228)
"load" (0x83d9f8)
"desktop-read" (0x83de80)
"if" (0x83e1f8)
"progn" (0x83e3c8)
"if" (0x83e598)
"desktop-settings-setup" (0x83e948)
"run-hooks" (0x83ea90)
"command-line" (0x83f058)
"normal-top-level" (0x83f4f0)

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 22 Mar 2015 19:59:41 +0000 (UTC)
> 
> > Also, can you show the Lisp object being read here?
> 
> I take any instruction to dig any further.
> I am a bit stuck on how to print even the lisp form that is evaluated.

The text being read is in current_buffer.  current_buffer->text->beg
points to the beginning of the text as a C string, and
current_buffer->pt_byte is the byte offset of point in that string.
If point is after the gap (whose value is current_buffer->text->gpt),
then it is more convenient to use BYTE_POS_ADDR to find the text where
point is.  That place is where you will find the offending Lisp
object.

Or just print the value of PT and then look inside the file at that
position.

Thanks for the backtraces, I hope someone will be able to use them to
figure out the problem.

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 22 Mar 2015 19:59:41 +0000 (UTC)
> 
> There is lots of bytecode which is executed during the backtrace.
> I don't know much about exploring those frames.

Ca you reproduce the problem by first starting "emacs -Q" and then
manually invoking 'desktop-read' to restore session from the offending
file?

If the above reproduces the crash, then you can produce a more
informative Lisp-level backtrace by manually loading all the Lisp
files involved as *.el files, after "emacs -Q" and before invoking
'desktop-read'.  In this case, I'd begin by loading desktop.el,
frameset.el, cl-lib.el, and undeo-tree.el.

Re: Emacs trunk crash

[Eli Zaretskii]

> Date: Sun, 22 Mar 2015 22:22:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> In this case, I'd begin by loading desktop.el, frameset.el,
> cl-lib.el, and undeo-tree.el.
                 ^^^^^

"undo", of course.

Btw, undo-tree is not part of Emacs, so perhaps it does something it
shouldn't.

Re: Emacs trunk crash

[Stefan Monnier]

> Btw, undo-tree is not part of Emacs,

Well, that's a philosophical discussion: it's in GNU ELPA, so it's
covered by copyright assignments to Emacs (so in this sense, it's part
of Emacs).

> so perhaps it does something it shouldn't.

Not really more likely than if it were a package bundled with Emacs.


        Stefan

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: fabrice.popineau@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 22 Mar 2015 18:35:01 -0400
> 
> > Btw, undo-tree is not part of Emacs,
> 
> Well, that's a philosophical discussion: it's in GNU ELPA, so it's
> covered by copyright assignments to Emacs (so in this sense, it's part
> of Emacs).
> 
> > so perhaps it does something it shouldn't.
> 
> Not really more likely than if it were a package bundled with Emacs.

Packages that are not bundled get less scrutiny from the core team, so
they are more likely to do questionable things, or fall out of sync.
On average, of course; I know nothing about undo-tree specifically.

Re: Emacs trunk crash

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

2015-03-22 21:22 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sun, 22 Mar 2015 19:59:41 +0000 (UTC)
> >
> > There is lots of bytecode which is executed during the backtrace.
> > I don't know much about exploring those frames.
>
> Ca you reproduce the problem by first starting "emacs -Q" and then
> manually invoking 'desktop-read' to restore session from the offending
> file?
>
> I have not yet been able to do that.
The culprit is this entry in my .emacs.desktop file:

(desktop-create-buffer 208
  "c:/Home/Research/Georges/indigolog/indigolog/indigolog-linux-0.8beta/lib/
eclipse_swi.pl"
  "eclipse_swi.pl"
  'prolog-mode
  '( )
  2570
  '(2359 nil)
  nil
  nil
  '((buffer-file-coding-system . undecided-unix) (truncate-lines))
  '((mark-ring (2570))))

I have removed all the minor modes which do not make a difference.
I have tried to change prolog-mode to fundamental-mode with no difference
either.

I can give the eclipse_swi.pl to whoever wants to debug this, but I suspect
that the bug
is triggered by something in my configuration. I'll try to find it.
(The file i available here
http://sourceforge.net/p/indigolog/code/ci/master/tree/lib/eclipse_swi.pl )

Fabrice

[-- Attachment #2: Type: text/html, Size: 2242 bytes --]

Re: Emacs trunk crash

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

2015-03-22 23:37 GMT+01:00 Fabrice Popineau <fabrice.popineau@gmail.com>:

>
>
> 2015-03-22 21:22 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>
>> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>> > Date: Sun, 22 Mar 2015 19:59:41 +0000 (UTC)
>> >
>> > There is lots of bytecode which is executed during the backtrace.
>> > I don't know much about exploring those frames.
>>
>> Ca you reproduce the problem by first starting "emacs -Q" and then
>> manually invoking 'desktop-read' to restore session from the offending
>> file?
>>
>> I have not yet been able to do that.
>

 The reason I couldn't do it yet is the following :
- I run "emacs -Q" (under gdb)
- I load a couple of libraries among which "desktop.el"
- I try to evaluate (desktop-create-buffer ...)
but it fails with "void variable desktop-buffer-ok-count"

Even if I evaluate the form:
(defvar desktop-buffer-ok-count) from the desktop.el file,
the variable is still unknown.

What could cause that ?

Fabrice

[-- Attachment #2: Type: text/html, Size: 1991 bytes --]

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 23 Mar 2015 06:32:55 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
>         Can you reproduce the problem by first starting "emacs -Q" and then
>         manually invoking 'desktop-read' to restore session from the offending
>         file?
>         
>         
> 
>     I have not yet been able to do that.
>     
> 
> The reason I couldn't do it yet is the following : 
> - I run "emacs -Q" (under gdb)
> - I load a couple of libraries among which "desktop.el"
> - I try to evaluate (desktop-create-buffer ...)
> but it fails with "void variable desktop-buffer-ok-count"
> 
> Even if I evaluate the form:
> (defvar desktop-buffer-ok-count) from the desktop.el file,
> the variable is still unknown.
> 
> What could cause that ?

I don't know, I never tried invoking desktop-create-buffer directly.

Did you try to invoke desktop-read, as I suggested?

Re: Emacs trunk crash

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 5516 bytes --]

I think I have found the real culprit behind this problem. The undo-tree
package
saves its history in a very direct form which looks like this:

"5c22c12309909a63b7377b79cf2526b92d756854"
[cl-struct-undo-tree [nil ([nil (#8=[nil nil ((19641 . 19642) (#(" " 0 1
(syntax-type string fontified nil)) . -19641) (undo-tree-id0 . -1) (19541 .
19547) (#(" " 0 1 (syntax-type string fontified nil)) . -19541)
(undo-tree-id1 . -1) (19469 . 19493) (#(" " 0 3 (syntax-type string)) .
-19469) (undo-tree-id2 . -3) (19330 . 19331) (#(" " 0 1 (syntax-type
string)) . -19330) (undo-tree-id3 . -1) (18803 . 18804) (#(" " 0 1
(syntax-type string fontified nil)) . -18803) (undo-tree-id4 . -1) (18365 .
18366) (#(" " 0 1 (syntax-type string)) . -18365) (undo-tree-id5 . -1)
(16435 . 16442) (#(" " 0 1 (syntax-type string)) . -16435) (undo-tree-id6 .
-1) (16250 . 16256) (#(" " 0 1 (syntax-type string)) . -16250)
(undo-tree-id7 . -1) (14242 . 14253) (#(" " 0 2 (syntax-type string)) .
-14242) (undo-tree-id8 . -2) (30156 . 30172) (#(" " 0 2 (syntax-type string
fontified nil)) . -30156) (undo-tree-id9 . -2) (26832 . 26864) (" " .
-26832) (undo-tree-id10 . -4) (25460 . 25468) (" " . -25460)
(undo-tree-id11 . -1) (25404 . 25412) (#(" " 0 1 (fontified nil)) . -25404)
(undo-tree-id12 . -1) (25265 . 25305) (" " . -25265) (undo-tree-id13 . -5)
(25195 . 25227) (" " . -25195) (undo-tree-id14 . -4) (25078 . 25118) (" " .
-25078) (undo-tree-id15 . -5) (25009 . 25049) (" " . -25009)
(undo-tree-id16 . -5) (24887 . 24895) (#(" " 0 1 (syntax-type string)) .
-24887) (undo-tree-id17 . -1) (24102 . 24110) (#(" " 0 1 (syntax-type
string)) . -24102) (undo-tree-id18 . -1) (24038 . 24046) (#(" " 0 1
(syntax-type string)) . -24038) (undo-tree-id19 . -1) (23986 . 23994) (#(" "
0 1 (syntax-type string)) . -23986) (undo-tree-id20 . -1) (23907 . 23914)
(#(" " 0 1 (syntax-type string)) . -23907) (undo-tree-id21 . -1) (23845 .
23853) (#(" " 0 1 (syntax-type string)) . -23845) (undo-tree-id22 . -1)
(23808 . 23815) (#(" " 0 1 (syntax-type string)) . -23808) (undo-tree-id23
. -1) (17359 . 17375) (#(" " 0 2 (syntax-type string)) . -17359)
(undo-tree-id24 . -2) (16588 . 16596) (#(" " 0 1 (syntax-type string)) .
-16588) (undo-tree-id25 . -1) (16532 . 16540) (#(" " 0 1 (syntax-type
string)) . -16532) (undo-tree-id26 . -1) (15993 . 16001) (#(" " 0 1
(syntax-type string)) . -15993) (undo-tree-id27 . -1) (15944 . 15952) (#(" "
0 1 (syntax-type string)) . -15944) (undo-tree-id28 . -1) (15918 . 15926)
(#(" " 0 1 (syntax-type string)) . -15918) (undo-tree-id29 . -1) (7553 .
7561) (#(" " 0 1 (syntax-type string)) . -7553) (undo-tree-id30 . -1) (7467
. 7475) (#(" " 0 1 (syntax-type string)) . -7467) (undo-tree-id31 . -1)
(2516 . 2524) (#(" " 0 1 (fontified t syntax-type string face
whitespace-space-after-tab)) . -2516) (undo-tree-id32 . -1) (2461 . 2469)
(#(" " 0 1 (fontified t syntax-type string face
whitespace-space-after-tab)) . -2461) (undo-tree-id33 . -1) (2317 . 2325)
(#(" " 0 1 (fontified t syntax-type string face
whitespace-space-after-tab)) . -2317) (undo-tree-id34 . 1) (undo-tree-id35
. 1) (undo-tree-id36 . -1) (1344 . 1352) (#(" " 0 1 (fontified t face
whitespace-space-after-tab)) . -1344) (undo-tree-id37 . 1) (undo-tree-id38
. 1) (undo-tree-id39 . -1) (1009 . 1017) (#(" " 0 1 (fontified t face
whitespace-space-after-tab)) . -1009) (undo-tree-id40 . 1) (undo-tree-id41
. 1) (undo-tree-id42 . -1) (#(" " 0 1 (syntax-table #7=#^[nil #^[#2=(0) nil
syntax-table #5=
#^^[3 0 #1=(1) #1# #1# #1# #1# #1# #1# #1# #1# #2# #2# #1# #2# #2# #1# #1#
#1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #1# #2# #1# (7)
#1# #3=(2) #3# #4=(3) #1# (4 . 41) (5 . 40) #4# #4# #1# #4# #1# #4# #3# #3#
#3# #3# #3# #3# #3# #3# #3# #3# #1# #1# #4# #4# #4# #1# #1# #3# #3# #3# #3#
#3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3#
#3# #3# #3# (4 . 93) (9) (5 . 91) #1# #4# #1# #3# #3# #3# #3# #3# #3# #3#
#3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3# #3#
(4 . 125) #4# (5 . 123) #1# #1#] #^^[1 0 #^^[2 0 #5#
...

I spare the rest, because the crash is happening while reading the form
starting at [cl-struct-undo-tree ...
Actually, the point is near the end of my lines on #^^[1

Emacs shouldn't crash while reading data it has been able to write (well,
at least I would expect it).
Could it be that the syntax-table structure has been changed recently in a
way that makes it impossible
to read one that has been printed with a previous version of emacs?

Fabrice


2015-03-23 16:34 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Mon, 23 Mar 2015 06:32:55 +0100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> >         Can you reproduce the problem by first starting "emacs -Q" and
> then
> >         manually invoking 'desktop-read' to restore session from the
> offending
> >         file?
> >
> >
> >
> >     I have not yet been able to do that.
> >
> >
> > The reason I couldn't do it yet is the following :
> > - I run "emacs -Q" (under gdb)
> > - I load a couple of libraries among which "desktop.el"
> > - I try to evaluate (desktop-create-buffer ...)
> > but it fails with "void variable desktop-buffer-ok-count"
> >
> > Even if I evaluate the form:
> > (defvar desktop-buffer-ok-count) from the desktop.el file,
> > the variable is still unknown.
> >
> > What could cause that ?
>
> I don't know, I never tried invoking desktop-create-buffer directly.
>
> Did you try to invoke desktop-read, as I suggested?
>

[-- Attachment #2: Type: text/html, Size: 8519 bytes --]

Re: Emacs trunk crash

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

2015-03-23 21:55 GMT+01:00 Fabrice Popineau <fabrice.popineau@gmail.com>:

>
> Emacs shouldn't crash while reading data it has been able to write (well,
> at least I would expect it).
> Could it be that the syntax-table structure has been changed recently in a
> way that makes it impossible
> to read one that has been printed with a previous version of emacs?
>
>
I should have said: in a previous _trunk_ version of emacs (couple of
months).

To make it clear: I can reproduce the crash from "emacs -Q" by evaluating
(read (current_buffer))
on a buffer containing the undo-tree history (part of which is in the
previous mail).
The point needs to be at the beginning of the [cl-struct-undo-tree .

Fabrice

[-- Attachment #2: Type: text/html, Size: 1258 bytes --]

Re: Emacs trunk crash

[Stefan Monnier]

>> Could it be that the syntax-table structure has been changed recently
>> in a way that makes it impossible to read one that has been printed
>> with a previous version of emacs?

Not that I know, no.

> To make it clear: I can reproduce the crash from "emacs -Q" by
> evaluating (read (current_buffer)) on a buffer containing the
> undo-tree history (part of which is in the previous mail).

That should make it easier to find the culprit, indeed.


        Stefan

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 23 Mar 2015 21:55:31 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I think I have found the real culprit behind this problem. The undo-tree
> package 
> saves its history in a very direct form which looks like this:
> 
> "5c22c12309909a63b7377b79cf2526b92d756854"
> [cl-struct-undo-tree [nil ([nil (#8=[nil nil ((19641 . 19642) (#(" " 0 1
> (syntax-type string fontified nil)) . -19641) (undo-tree-id0 . -1) (19541 .
> 
> I spare the rest, because the crash is happening while reading the form
> starting at [cl-struct-undo-tree ...
> Actually, the point is near the end of my lines on #^^[1
> 
> Emacs shouldn't crash while reading data it has been able to write (well, at
> least I would expect it).
> Could it be that the syntax-table structure has been changed recently in a way
> that makes it impossible 
> to read one that has been printed with a previous version of emacs?

I can't reproduce the crash, I get

  (args-out-of-range 0 3)

Can you post the full buffer, or at least a part that can be used as a
reproducer?

Re: Emacs trunk crash

[Fabrice Popineau]

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

The file is attached.
Put the point at the beginning of the second line on the bracket
and M-: (read (current-buffer))

Fabrice

2015-03-24 18:23 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Mon, 23 Mar 2015 21:55:31 +0100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > I think I have found the real culprit behind this problem. The undo-tree
> > package
> > saves its history in a very direct form which looks like this:
> >
> > "5c22c12309909a63b7377b79cf2526b92d756854"
> > [cl-struct-undo-tree [nil ([nil (#8=[nil nil ((19641 . 19642) (#(" " 0 1
> > (syntax-type string fontified nil)) . -19641) (undo-tree-id0 . -1)
> (19541 .
> >
> > I spare the rest, because the crash is happening while reading the form
> > starting at [cl-struct-undo-tree ...
> > Actually, the point is near the end of my lines on #^^[1
> >
> > Emacs shouldn't crash while reading data it has been able to write
> (well, at
> > least I would expect it).
> > Could it be that the syntax-table structure has been changed recently in
> a way
> > that makes it impossible
> > to read one that has been printed with a previous version of emacs?
>
> I can't reproduce the crash, I get
>
>   (args-out-of-range 0 3)
>
> Can you post the full buffer, or at least a part that can be used as a
> reproducer?
>

[-- Attachment #1.2: Type: text/html, Size: 1994 bytes --]

[-- Attachment #2: foo.el.gz --]
[-- Type: application/x-gzip, Size: 2860 bytes --]

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 24 Mar 2015 22:10:16 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> The file is attached.
> Put the point at the beginning of the second line on the bracket
> and M-: (read (current-buffer))

Try the patch below.  It solves the crash with the file you sent, but
the question is: does it also solve your real-life use case?

diff --git a/src/lread.c b/src/lread.c
index ae17529..050e43e 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -3280,7 +3280,7 @@ BUFFER is the buffer to evaluate (nil means use current buffer).
     {
     case Lisp_Vectorlike:
       {
-	ptrdiff_t i, length = 0;
+	ptrdiff_t i = 0, length = 0;
 	if (BOOL_VECTOR_P (subtree))
 	  return subtree;		/* No sub-objects anyway.  */
 	else if (CHAR_TABLE_P (subtree) || SUB_CHAR_TABLE_P (subtree)
@@ -3295,7 +3295,9 @@ BUFFER is the buffer to evaluate (nil means use current buffer).
 	     behavior.  */
 	  wrong_type_argument (Qsequencep, subtree);
 
-	for (i = 0; i < length; i++)
+	if (SUB_CHAR_TABLE_P (subtree))
+	  i = 2;
+	for ( ; i < length; i++)
 	  SUBSTITUTE (AREF (subtree, i),
 		      ASET (subtree, i, true_value));
 	return subtree;

Re: Emacs trunk crash

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

2015-03-27 10:52 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Wed, 25 Mar 2015 23:16:45 +0100
> >
> > 2015-03-25 21:38 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> >
> >     Try the patch below. It solves the crash with the file you sent, but
> >     the question is: does it also solve your real-life use case?
> >
> >
> > Great! If you have an explanation about what is happening there, it
> would be
> > great too.
> > About my real life case : that was the actual file preventing emacs to
> run
> > because of the crash.
> > In all the undo-tree history files, only this one had a dumped syntax
> table.
> > I have no idea why undo-tree wants to do that.
> > But in any case, emacs shouldn't crash when reading data that it has
> printed
> > itself.
>
> Did you try the patch?  Can I commit it?
>


Yes. You should commit it in my opinion. I don't know if something else
needs to be patched, but reviving the same
state that was crashing, emacs could start and I was able to undo stuff
from the undo-tree-history.

Thanks a lot for the patch.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1892 bytes --]

Re: Emacs trunk crash

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 27 Mar 2015 11:41:10 +0100
> 
>     Did you try the patch? Can I commit it?
> 
> Yes. You should commit it in my opinion.

Done.

Re: Emacs trunk crash

[martin rudalics]

 > This is the consequence of an unattented shutdown of my machine with a long
 > emacs session running. I'm not sure I'll be able to reproduce it at all. But for
 > the time being, I'm unable to restart my session. Emacs is crashing while
 > restoring one of the files of my session.

Please make sure to not overwrite that desktop file so we can analyze
what happens.

martin