bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Christoph Scholtes]

Emacs 24.1.50, bzr revno 108131 on Windows 7.

Emacs crashed with an w32_abort() in Fadd_text_properties() when 
capturing a task in org-mode.

I still have the session running and can provide further debugging.

Backtrace as follows:
Thread 1 (thread 964.0xc50):
#0  0x76ad280d in KERNELBASE!DeleteAce ()
    from C:\Windows\syswow64\KernelBase.dll
#1  0x0114e7e6 in w32_abort () at w32fns.c:233
#2  0x01263a6c in Fadd_text_properties (start=1232, end=1236,
     properties=280626054, object=283151365) at textprop.c:129
#3  0x010341c8 in eval_sub (form=283940270) at eval.c:175
#4  0x0102f976 in Fprogn (args=283940094) at eval.c:175
#5  0x010314d9 in Flet (args=283940278) at eval.c:175
#6  0x01033c57 in eval_sub (form=283940870) at eval.c:175
#7  0x0102f976 in Fprogn (args=283939934) at eval.c:175
#8  0x01036d01 in funcall_lambda (fun=283970126, nargs=3, 
arg_vector=0x88c590)
     at eval.c:175
#9  0x01036646 in apply_lambda (fun=283970126, args=283967678) at eval.c:175
#10 0x010345bd in eval_sub (form=283967686) at eval.c:175
#11 0x0102f976 in Fprogn (args=283967654) at eval.c:175
#12 0x01031068 in FletX (args=283967694) at eval.c:175
#13 0x01033c57 in eval_sub (form=283967814) at eval.c:175
#14 0x0102f976 in Fprogn (args=283967646) at eval.c:175
#15 0x0102f8cd in Fcond (args=283967638) at eval.c:175
#16 0x01033c57 in eval_sub (form=283969158) at eval.c:175
#17 0x0102f976 in Fprogn (args=283967630) at eval.c:175
#18 0x01031565 in Fwhile (args=283969166) at eval.c:175
#19 0x01033c57 in eval_sub (form=283969254) at eval.c:175
#20 0x0102f976 in Fprogn (args=280388286) at eval.c:175
#21 0x01033c57 in eval_sub (form=280375438) at eval.c:175
#22 0x01031ab3 in Funwind_protect (args=280632942) at eval.c:175
#23 0x01033c57 in eval_sub (form=280632934) at eval.c:175
#24 0x0102f976 in Fprogn (args=280632926) at eval.c:175
#25 0x01031068 in FletX (args=280632902) at eval.c:175
#26 0x01033c57 in eval_sub (form=280632894) at eval.c:175
#27 0x01034592 in eval_sub (form=283969262) at eval.c:175
#28 0x0102f976 in Fprogn (args=283967614) at eval.c:175
#29 0x01031068 in FletX (args=283969270) at eval.c:175
#30 0x01033c57 in eval_sub (form=283969934) at eval.c:175
#31 0x0102f976 in Fprogn (args=280391254) at eval.c:175
#32 0x011052bf in Fsave_restriction (body=280389926) at buffer.h:1056
#33 0x01033c57 in eval_sub (form=280389918) at eval.c:175
#34 0x0102f976 in Fprogn (args=280389910) at eval.c:175
#35 0x010fec7e in Fsave_excursion (args=280389910) at buffer.h:1056
#36 0x01033c57 in eval_sub (form=280389902) at eval.c:175
#37 0x01034592 in eval_sub (form=283969982) at eval.c:175
#38 0x0102f976 in Fprogn (args=280391382) at eval.c:175
#39 0x01033c57 in eval_sub (form=280391374) at eval.c:175
#40 0x01031ab3 in Funwind_protect (args=280391358) at eval.c:175
#41 0x01033c57 in eval_sub (form=280391334) at eval.c:175
#42 0x0102f976 in Fprogn (args=280391326) at eval.c:175
#43 0x010314d9 in Flet (args=280391286) at eval.c:175
#44 0x01033c57 in eval_sub (form=280391278) at eval.c:175
#45 0x01034592 in eval_sub (form=283969990) at eval.c:175
#46 0x0102f976 in Fprogn (args=283967590) at eval.c:175
#47 0x01036d01 in funcall_lambda (fun=283967582, nargs=2, 
arg_vector=0x88da80)
     at eval.c:175
#48 0x01036646 in apply_lambda (fun=283967582, args=283966670) at eval.c:175
#49 0x010345bd in eval_sub (form=283966678) at eval.c:175
#50 0x0102f976 in Fprogn (args=283966654) at eval.c:175
#51 0x010314d9 in Flet (args=283966718) at eval.c:175
#52 0x01033c57 in eval_sub (form=283966966) at eval.c:175
#53 0x0102f7e8 in Fif (args=283966974) at eval.c:175
#54 0x01033c57 in eval_sub (form=283967142) at eval.c:175
#55 0x0102f976 in Fprogn (args=279741150) at eval.c:175
#56 0x01033c57 in eval_sub (form=279741142) at eval.c:175
#57 0x01031ab3 in Funwind_protect (args=279741126) at eval.c:175
#58 0x01033c57 in eval_sub (form=279741118) at eval.c:175
#59 0x0102f976 in Fprogn (args=279741110) at eval.c:175
#60 0x010314d9 in Flet (args=279741102) at eval.c:175
#61 0x01033c57 in eval_sub (form=279741094) at eval.c:175
#62 0x01034592 in eval_sub (form=283967150) at eval.c:175
#63 0x0102f976 in Fprogn (args=279741230) at eval.c:175
#64 0x01033c57 in eval_sub (form=279741222) at eval.c:175
#65 0x0102f7e8 in Fif (args=279741190) at eval.c:175
#66 0x01033c57 in eval_sub (form=279741182) at eval.c:175
#67 0x01034592 in eval_sub (form=283967166) at eval.c:175
#68 0x0102f976 in Fprogn (args=283966590) at eval.c:175
#69 0x01036d01 in funcall_lambda (fun=283966582, nargs=3, 
arg_vector=0x88e8e8)
     at eval.c:175
#70 0x010363df in Ffuncall (nargs=4, args=0x88e8e4) at eval.c:175
#71 0x01034f2c in funcall_nil (nargs=4, args=0x88e8e4) at eval.c:175
#72 0x0103534b in run_hook_with_args (nargs=4, args=0x88e8e4,
     funcall=0x1034f14 <funcall_nil>) at eval.c:175
#73 0x01034f9d in Frun_hook_with_args (nargs=4, args=0x88e8e4) at eval.c:175
#74 0x01115c0c in signal_after_change (charpos=129, lendel=0, lenins=56)
     at insdel.c:91
#75 0x01112494 in insert_from_string (string=281887745, pos=0, pos_byte=0,
     length=56, length_byte=56, inherit=0) at insdel.c:91
#76 0x011016c0 in general_insert_function (insert_func=0x1111cb6 <insert>,
     insert_from_string_func=0x11123ef <insert_from_string>, inherit=0,
     nargs=1, args=0x88e9f0) at buffer.h:1056
#77 0x01101733 in Finsert (nargs=1, args=0x88e9f0) at buffer.h:1056
#78 0x01033ed4 in eval_sub (form=277589190) at eval.c:175
#79 0x0102f976 in Fprogn (args=277589110) at eval.c:175
#80 0x01033c57 in eval_sub (form=277589678) at eval.c:175
#81 0x0102f7e8 in Fif (args=277589686) at eval.c:175
#82 0x01033c57 in eval_sub (form=277589790) at eval.c:175
#83 0x0102f976 in Fprogn (args=277588270) at eval.c:175
#84 0x010314d9 in Flet (args=277589822) at eval.c:175
#85 0x01033c57 in eval_sub (form=277589918) at eval.c:175
#86 0x0102f976 in Fprogn (args=277588262) at eval.c:175
#87 0x01036d01 in funcall_lambda (fun=277588254, nargs=1, 
arg_vector=0x88ef90)
     at eval.c:175
#88 0x01036646 in apply_lambda (fun=277588254, args=277772430) at eval.c:175
#89 0x010345bd in eval_sub (form=277772438) at eval.c:175
#90 0x0102f976 in Fprogn (args=285388366) at eval.c:175
#91 0x01033c57 in eval_sub (form=285388358) at eval.c:175
#92 0x0102f7e8 in Fif (args=285388342) at eval.c:175
#93 0x01033c57 in eval_sub (form=285388334) at eval.c:175
#94 0x01034592 in eval_sub (form=277772534) at eval.c:175
#95 0x0102f976 in Fprogn (args=277772414) at eval.c:175
#96 0x01036d01 in funcall_lambda (fun=277772406, nargs=0, 
arg_vector=0x88f4d0)
     at eval.c:175
#97 0x01036646 in apply_lambda (fun=277772406, args=58206234) at eval.c:175
#98 0x010345bd in eval_sub (form=277652966) at eval.c:175
#99 0x0102f976 in Fprogn (args=277652958) at eval.c:175
#100 0x0102f8cd in Fcond (args=277646286) at eval.c:175
#101 0x01033c57 in eval_sub (form=277654182) at eval.c:175
#102 0x0102f976 in Fprogn (args=277646278) at eval.c:175
#103 0x01036d01 in funcall_lambda (fun=277646270, nargs=1,
     arg_vector=0x88f914) at eval.c:175
#104 0x010363df in Ffuncall (nargs=2, args=0x88f910) at eval.c:175
#105 0x010e2870 in Fcall_interactively (function=281678850,
     record_flag=58206234, keys=58227461) at callint.c:129
#106 0x01035fe5 in Ffuncall (nargs=4, args=0x88fb40) at eval.c:175
#107 0x01035501 in call3 (fn=58326354, arg1=281678850, arg2=58206234,
     arg3=58206234) at eval.c:175
#108 0x0101fa28 in Fcommand_execute (cmd=281678850, record_flag=58206234,
     keys=58206234, special=58206234) at buffer.h:1056
#109 0x010065be in command_loop_1 () at buffer.h:1056
#110 0x10ca1402 in ?? ()
#111 0x0378281a in __register_frame_info ()
#112 0x0378281a in __register_frame_info ()
#113 0x0378281a in __register_frame_info ()
#114 0x00000001 in ?? ()
#115 0x00000001 in ?? ()
#116 0x0378281a in __register_frame_info ()
#117 0x107c8971 in ?? ()
#118 0x03bf7aea in __register_frame_info ()
#119 0x000001bc in ?? ()
#120 0x000001c8 in ?? ()
#121 0x00000000 in ?? ()


Christoph

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Eli Zaretskii]

> Date: Sat, 05 May 2012 21:18:56 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> 
> Emacs 24.1.50, bzr revno 108131 on Windows 7.
> 
> Emacs crashed with an w32_abort() in Fadd_text_properties() when 
> capturing a task in org-mode.
> 
> I still have the session running and can provide further debugging.
> 
> Backtrace as follows:
> Thread 1 (thread 964.0xc50):
> #0  0x76ad280d in KERNELBASE!DeleteAce ()
>     from C:\Windows\syswow64\KernelBase.dll
> #1  0x0114e7e6 in w32_abort () at w32fns.c:233
> #2  0x01263a6c in Fadd_text_properties (start=1232, end=1236,
>      properties=280626054, object=283151365) at textprop.c:129

What is 'object' in frame #2?

Also, please show the Lisp backtrace.

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

 > What is 'object' in frame #2?

from bt full:

#2  0x01263a6c in Fadd_text_properties (start=1232, end=1236,
     properties=280626054, object=283151365) at textprop.c:129
     i = (INTERVAL) 0x0
     unchanged = (INTERVAL) 0x88c374
     s = 308
     len = 1
     modified = 0
     gcpro1 = {
   next = 0x2,
   var = 0x88c150,
   nvars = 58206234

 > Also, please show the Lisp backtrace.

Lisp Backtrace:
"add-text-properties" (0x88c284)
"let" (0x88c49c)
"org-indent-set-line-properties" (0x88c590)
"let*" (0x88c82c)
"cond" (0x88c97c)
"while" (0x88cadc)
"progn" (0x88cbfc)
"unwind-protect" (0x88cd1c)
"let*" (0x88ce9c)
"with-silent-modifications" (0x88cf8c)
"let*" (0x88d10c)
"save-restriction" (0x88d25c)
"save-excursion" (0x88d3ac)
"org-with-wide-buffer" (0x88d49c)
"progn" (0x88d5bc)
"unwind-protect" (0x88d6dc)
"let" (0x88d89c)
"save-match-data" (0x88d98c)
"org-indent-add-properties" (0x88da80)
"let" (0x88dd5c)
"if" (0x88de7c)
"progn" (0x88df9c)
"unwind-protect" (0x88e0bc)
"let" (0x88e27c)
"save-match-data" (0x88e36c)
"progn" (0x88e48c)
"if" (0x88e5ac)
"when" (0x88e69c)
"org-indent-refresh-maybe" (0x88e8e8)
"insert" (0x88e9f0)
"progn" (0x88ebac)
"if" (0x88eccc)
"let" (0x88ee9c)
"org-align-tags-here" (0x88ef90)
"progn" (0x88f1cc)
"if" (0x88f2ec)
"when" (0x88f3dc)
"org-fix-tags-on-the-fly" (0x88f4d0)
"cond" (0x88f72c)
"org-self-insert-command" (0x88f914)
"call-interactively" (0x88fb44)

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Eli Zaretskii]

> Date: Sun, 06 May 2012 12:26:24 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: 11416@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>  > What is 'object' in frame #2?
> 
> from bt full:
> 
> #2  0x01263a6c in Fadd_text_properties (start=1232, end=1236,
>      properties=280626054, object=283151365) at textprop.c:129
>      i = (INTERVAL) 0x0
>      unchanged = (INTERVAL) 0x88c374
>      s = 308
>      len = 1
>      modified = 0
>      gcpro1 = {
>    next = 0x2,
>    var = 0x88c150,
>    nvars = 58206234

Sorry, I should have been more clear.  I meant this:

 (gdb) p object
 (gdb) xtype

If "xtype" says it's a symbol, follow immediately by "xsymbol" to see
which symbol it is.  Other Lisp data types have their respective xFOO
commands to do similar things.

Btw, is this an optimized build?  I didn't pay attention before, but I
see now that the C backtrace is entirely bogus: almost all frames
there are "at eval.c:175", which is obviously nonsense, since the
function names are different.  The place where abort was called,
claimed to be textprop.c:129, is also a lie, as nothing around that
line can ever call abort (unless I'm missing something).  I'm guessing
it actually aborted at line 1194:

      if (i == 0)
	abort ();

Not sure what that means, though.

And what versions of GCC and GDB did you use?

> Lisp Backtrace:
> "add-text-properties" (0x88c284)
> "let" (0x88c49c)
> "org-indent-set-line-properties" (0x88c590)
> "let*" (0x88c82c)
> "cond" (0x88c97c)
> "while" (0x88cadc)
> "progn" (0x88cbfc)
> "unwind-protect" (0x88cd1c)
> "let*" (0x88ce9c)
> "with-silent-modifications" (0x88cf8c)
> "let*" (0x88d10c)
> "save-restriction" (0x88d25c)
> "save-excursion" (0x88d3ac)
> "org-with-wide-buffer" (0x88d49c)
> "progn" (0x88d5bc)
> "unwind-protect" (0x88d6dc)
> "let" (0x88d89c)
> "save-match-data" (0x88d98c)
> "org-indent-add-properties" (0x88da80)
> "let" (0x88dd5c)
> "if" (0x88de7c)
> "progn" (0x88df9c)
> "unwind-protect" (0x88e0bc)
> "let" (0x88e27c)
> "save-match-data" (0x88e36c)
> "progn" (0x88e48c)
> "if" (0x88e5ac)
> "when" (0x88e69c)
> "org-indent-refresh-maybe" (0x88e8e8)
> "insert" (0x88e9f0)
> "progn" (0x88ebac)
> "if" (0x88eccc)
> "let" (0x88ee9c)
> "org-align-tags-here" (0x88ef90)
> "progn" (0x88f1cc)
> "if" (0x88f2ec)
> "when" (0x88f3dc)
> "org-fix-tags-on-the-fly" (0x88f4d0)
> "cond" (0x88f72c)
> "org-self-insert-command" (0x88f914)
> "call-interactively" (0x88fb44)

Any hope of you remembering what you did at that point?

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

 > Sorry, I should have been more clear.  I meant this:
 >
 >  (gdb) p object
 >  (gdb) xtype
 >
 > If "xtype" says it's a symbol, follow immediately by "xsymbol" to see
 > which symbol it is.  Other Lisp data types have their respective xFOO
 > commands to do similar things.

(gdb) p object
$6 = 283151365
(gdb) xtype
Lisp_Vectorlike
PVEC_BUFFER
(gdb) xvector
$7 = (struct Lisp_Vector *) 0x10e08c00
0
(gdb)

 > Btw, is this an optimized build?  I didn't pay attention before, but I
 > see now that the C backtrace is entirely bogus: almost all frames
 > there are "at eval.c:175", which is obviously nonsense, since the
 > function names are different.  The place where abort was called,
 > claimed to be textprop.c:129, is also a lie, as nothing around that
 > line can ever call abort (unless I'm missing something).  I'm guessing
 > it actually aborted at line 1194:
 >
 >       if (i == 0)
 >     abort ();
 >
 > Not sure what that means, though.

No, it's a debug nightly build from my Jenkins server. However, last
night another build got kicked of and some files might haeve been
updated from bzr. The build failed since the executable was still
running. Possible that the source does not match the object code.

 > And what versions of GCC and GDB did you use?

gcc 4.6.2. gdb 6.8, which I used by accident, but there is nothing I can 
do now.
gdb 7.3.1 is the usual version I use.

 > Any hope of you remembering what you did at that point?

Sure. I was using C-C r to trigger org-capture and then entering a line
into an org-capture template when it crashed.

If this doesn't lead to anything, I can keep an eye open for another
occurrence.

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Eli Zaretskii]

> Date: Sun, 06 May 2012 13:53:19 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: 11416@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>  > Sorry, I should have been more clear.  I meant this:
>  >
>  >  (gdb) p object
>  >  (gdb) xtype
>  >
>  > If "xtype" says it's a symbol, follow immediately by "xsymbol" to see
>  > which symbol it is.  Other Lisp data types have their respective xFOO
>  > commands to do similar things.
> 
> (gdb) p object
> $6 = 283151365
> (gdb) xtype
> Lisp_Vectorlike
> PVEC_BUFFER
> (gdb) xvector
> $7 = (struct Lisp_Vector *) 0x10e08c00
> 0
> (gdb)

So it's a buffer.  "xbuffer" will show more details (but I'm not sure
this is worth pursuing, until we establish where exactly does Emacs
abort and why).

> No, it's a debug nightly build from my Jenkins server. However, last
> night another build got kicked of and some files might haeve been
> updated from bzr. The build failed since the executable was still
> running. Possible that the source does not match the object code.

Could it be that the abort was caused by compiling/linking
incompatible files?

> gdb 7.3.1 is the usual version I use.

I suggest upgrading to the latest v7.4 (available from MinGW).

> If this doesn't lead to anything, I can keep an eye open for another
> occurrence.

Sounds like this is the way to go.  Start Emacs from GDB, while you
are at it, so that "pp" etc. works.

Thanks.

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

 > So it's a buffer.  "xbuffer" will show more details (but I'm not sure
 > this is worth pursuing, until we establish where exactly does Emacs
 > abort and why).

(gdb) p object
$8 = 283151365
(gdb) xtype
Lisp_Vectorlike
PVEC_BUFFER
(gdb) xbuffer
$9 = (struct buffer *) 0x10e08c00
(unsigned char *) 0x110305d8 "CAPTURE-refile.org"
(gdb)

That's the buffer that is created by org-capture and that I was working in.

 > Could it be that the abort was caused by compiling/linking
 > incompatible files?

No, the crash happened last night (before midnight), so it was the
previous night's build. The build process was restarted at midnight but
failed since the instance was still running with gdb attached.

 > I suggest upgrading to the latest v7.4 (available from MinGW).

Cool. Will do.

 > Sounds like this is the way to go.  Start Emacs from GDB, while you
 > are at it, so that "pp" etc. works.

OK.

bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows

[Glenn Morris]

It's been ~ 300 days with no more information, so I am assuming this
crash report is no longer relevant. If it is, please reopen (or make a
new report).