bug#13941: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 12 Mar 2013 19:21:22 -0700
> 
>  
>  
> Backtrace:
> 0x01158AA0
> 0x01158B12
> 0x0101EAED
> 0x01017FC6
> 0x010146F0
> 0x010E35F7
> 0x010E29BE
> 0x01013031
> 0x01010720
> 0x010E418B
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x010E29BE
> 0x01013031
> 0x01010BE1
> 0x010E4234
> 0x01015C17
> 0x010150A8
> 0x0101369D
> 0x01012DA6
> 0x0100F0E2
> 0x01015AE2
> 0x0101517A
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x010144C4
> 0x010C2BAF
> 0x010130B2
> 0x01010BE1
> 0x010E4234
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x010E29BE
> 0x01013031
> 0x01010BE1
> 0x010E4234
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x01012DA6
> 0x01010BE1
> 0x010E4234
> 0x01015C17
> 0x010150A8
> 0x010E35F7
> 0x01015C17
> 0x010150A8
> 0x01012DA6
> ...

This crash is in GC:

  w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7727
  emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7759
  Fgarbage_collect at C:\Devel\emacs\repo\build\src/alloc.c:5207
  maybe_gc at C:\Devel\emacs\repo\build\src/lisp.h:3823
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2626
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  Fbyte_code at C:\Devel\emacs\repo\build\src/bytecode.c:473
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2046
  internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1079
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  Fbyte_code at C:\Devel\emacs\repo\build\src/bytecode.c:473
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2046
  internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1094
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  Fapply at C:\Devel\emacs\repo\build\src/eval.c:2156
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2012
  Fprogn at C:\Devel\emacs\repo\build\src/eval.c:359
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2900
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2736
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  call3 at C:\Devel\emacs\repo\build\src/eval.c:2500
  Fall_completions at C:\Devel\emacs\repo\build\src/minibuf.c:1524
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2050
  internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1094
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  Fbyte_code at C:\Devel\emacs\repo\build\src/bytecode.c:473
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2046
  internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1094
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2012
  internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1094
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:898
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2907
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2724
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2012

Dmitry, could you take a look?  It crashes here:

  DEFUN ("garbage-collect", Fgarbage_collect, Sgarbage_collect, 0, 0, "",
         doc: /* Reclaim storage for Lisp objects no longer needed.
  Garbage collection happens automatically if you cons more than
  `gc-cons-threshold' bytes of Lisp data since previous garbage collection.
  `garbage-collect' normally returns a list with info on amount of space in use,
  where each entry has the form (NAME SIZE USED FREE), where:
  - NAME is a symbol describing the kind of objects this entry represents,
  - SIZE is the number of bytes used by each one,
  - USED is the number of those objects that were found live in the heap,
  - FREE is the number of those objects that are not live but that Emacs
    keeps around for future allocations (maybe because it does not know how
    to return them to the OS).
  However, if there was overflow in pure space, `garbage-collect'
  returns nil, because real GC can't be done.
  See Info node `(elisp)Garbage Collection'.  */)
    (void)
  {
    struct specbinding *bind;
    struct buffer *nextb;
    char stack_top_variable;
    ptrdiff_t i;
    bool message_p;
    ptrdiff_t count = SPECPDL_INDEX ();
    EMACS_TIME start;
    Lisp_Object retval = Qnil;
    size_t tot_before = 0;
    struct backtrace backtrace;

    if (abort_on_gc)
      emacs_abort ();   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The only place that sets abort_on_gc is in prin1-to-string.  I don't
see it in the above backtrace, but since the backtrace was too long
and was truncated, it is possible that it was called.  Or not.