bug#23233: 25.0.92; Crash after doing much work in Proof General

bug#23233: 25.0.92; Crash after doing much work in Proof General

[John Wiegley]

I'm not sure how helpful this report is going to be, but:

These days I configure with the following flags:

           [ "--with-ns" "--disable-ns-self-contained"
             "--enable-checking=yes"
             "--enable-check-lisp-object-type=yes" ]

And pass -O0 -g3 to make.  I also run under lldb, to catch any exceptions.

After using Emacs (built just today) for many hours, I found myself needing to
kill a Coq buffer, which apparently prompted a GC.  It was during this GC that
it died.

Nothing that I was doing was out of the ordinary for me, and Emacs has been
running strong for weeks, so there's a subtle edge case here that I'm unable
to reduce into something smaller.

I'm reporting this in case it's something that can be gleaned from reading the
trace.  Otherwise, feel free to close and I will keep looking for a pattern.

    http://dl.dropbox.com/u/137615/info.txt

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 05 Apr 2016 22:08:53 -0700
> 
> After using Emacs (built just today) for many hours, I found myself needing to
> kill a Coq buffer, which apparently prompted a GC.  It was during this GC that
> it died.
> 
> Nothing that I was doing was out of the ordinary for me, and Emacs has been
> running strong for weeks, so there's a subtle edge case here that I'm unable
> to reduce into something smaller.
> 
> I'm reporting this in case it's something that can be gleaned from reading the
> trace.  Otherwise, feel free to close and I will keep looking for a pattern.
> 
>     http://dl.dropbox.com/u/137615/info.txt

How much stack do you have there for the Emacs executable?  The stack
trace looks like infinite recursion to me, repeating this sequence ad
nauseam:

    frame #27912: 0x0000000100330ae4 Emacs`call1 + 68
    frame #27913: 0x000000010034d407 Emacs`mapcar1 + 1095
    frame #27914: 0x0000000100350fc5 Emacs`Fmapcar + 15109
    frame #27915: 0x000000010032fac8 Emacs`Ffuncall + 1432
    frame #27916: 0x00000001003bf9bc Emacs`exec_byte_code + 5196
    frame #27917: 0x00000001003319e3 Emacs`funcall_lambda + 2739
    frame #27918: 0x000000010032fdeb Emacs`Ffuncall + 2235
    frame #27919: 0x00000001003bf9bc Emacs`exec_byte_code + 5196
    frame #27920: 0x00000001003319e3 Emacs`funcall_lambda + 2739
    frame #27921: 0x000000010032fdeb Emacs`Ffuncall + 2235

with minor variations.  This starts from running a hook:

    frame #28069: 0x000000010033072c Emacs`run_hook_with_args + 1308
    frame #28070: 0x00000001003301f4 Emacs`Frun_hook_with_args + 36
    frame #28071: 0x00000001003301bf Emacs`run_hook + 31
    frame #28072: 0x0000000100330177 Emacs`Frun_hooks + 55

so maybe one of your hooks incurs infinite recursion?

bug#23233: 25.0.92; Crash after doing much work in Proof General

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> with minor variations.  This starts from running a hook:

>     frame #28069: 0x000000010033072c Emacs`run_hook_with_args + 1308
>     frame #28070: 0x00000001003301f4 Emacs`Frun_hook_with_args + 36
>     frame #28071: 0x00000001003301bf Emacs`run_hook + 31
>     frame #28072: 0x0000000100330177 Emacs`Frun_hooks + 55

> so maybe one of your hooks incurs infinite recursion?

I suppose it's always possible, but I wonder then why I don't see this more
often. I'll look for recursions the next time it happens. For now, I'll keep
Emacs under lldb with full debugging (which does make it noticeably slower).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> with minor variations.  This starts from running a hook:
>
>>     frame #28069: 0x000000010033072c Emacs`run_hook_with_args + 1308
>>     frame #28070: 0x00000001003301f4 Emacs`Frun_hook_with_args + 36
>>     frame #28071: 0x00000001003301bf Emacs`run_hook + 31
>>     frame #28072: 0x0000000100330177 Emacs`Frun_hooks + 55
>
>> so maybe one of your hooks incurs infinite recursion?
>
> I suppose it's always possible, but I wonder then why I don't see this more
> often. I'll look for recursions the next time it happens. For now, I'll keep
> Emacs under lldb with full debugging (which does make it noticeably slower).

Well, an infinite hook recursion still shouldn't make Emacs crash.

The backtrace reminded me a bit about the known gc recursion bug that I
can't remember the recipe for right now -- it was something about if you
(setcar foo foo), then Emacs will segfault when trying to gc?  I forget
the details, but it's in the debbugs somewhere.  :-)

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

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The backtrace reminded me a bit about the known gc recursion bug that I
> can't remember the recipe for right now -- it was something about if you
> (setcar foo foo), then Emacs will segfault when trying to gc?  I forget
> the details, but it's in the debbugs somewhere.  :-)

Circular structures are of course not a problem, since gc will never
revisit an object it already saw.  You need deeply nested structures.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 07 Apr 2016 00:13:05 +0200
> 
> Well, an infinite hook recursion still shouldn't make Emacs crash.

Infinite recursion will crash any program due to stack overflow.

> The backtrace reminded me a bit about the known gc recursion bug that I
> can't remember the recipe for right now -- it was something about if you
> (setcar foo foo), then Emacs will segfault when trying to gc?  I forget
> the details, but it's in the debbugs somewhere.  :-)

I don't think this is what happened in this case.  If indeed the stack
was exhausted (by having ~1000 call frames before GC started), the
crash has nothing to do with GC itself, except that GC is inherently
recursive.

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Markus Triska]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The backtrace reminded me a bit about the known gc recursion bug that I
> can't remember the recipe for right now -- it was something about if you
> (setcar foo foo), then Emacs will segfault when trying to gc?  I forget
> the details, but it's in the debbugs somewhere.  :-)

Please see #2099.

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: bug-gnu-emacs@gnu.org
> Date: Wed, 06 Apr 2016 14:41:22 -0700
> 
> For now, I'll keep Emacs under lldb with full debugging (which does
> make it noticeably slower).

Running under a debugger should never slow down Emacs, unless you set
breakpoints with ignore conditions.

bug#23233: 25.0.92; Crash after doing much work in Proof General

[Glenn Morris]

John Wiegley wrote:

> I'm reporting this in case it's something that can be gleaned from
> reading the trace. Otherwise, feel free to close and I will keep
> looking for a pattern.

Exercising that freedom. :)