Subject: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows

From: Eli Zaretskii <[email-masked]>
Date: Mon, 01 Oct 2012 10:12:45 +0200

> From: Fabrice Popineau <[email-masked]>
> Date: Mon, 1 Oct 2012 09:31:14 +0200
> Cc: [email-masked]
> 
> I don't know if it is related or not, but I get a few crashes too when
> doing a bootstrap and
> while compiling some .el files. An example of a backtrace is :
> And the crash occurs after a
> 
> EnterCriticalSection(crit)
> 
> instruction.
> I have the same behaviour with both 32bits and 64bits exe.

The backtrace looks completely different from what Juanma shows in his
crashes, FWIW.

>   ntdll.dll!RtlDeNormalizeProcessParams()  + 0x5a4 bytes
>   [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
>   ntdll.dll!RtlDeNormalizeProcessParams()  + 0x4cb bytes
> > emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
>  Line 642 C
>   emacs.exe!set_alarm()  Line 326 C
>   emacs.exe!do_pending_atimers()  Line 397 C
>   emacs.exe!totally_unblock_input()  Line 7168 C
>   emacs.exe!terminate_due_to_signal(int sig, int backtrace_limit)  Line 297
> C
>   emacs.exe!deliver_fatal_thread_signal(int sig)  Line 1570 + 0x12 bytes C
>   msvcr100.dll!_XcptFilter()  + 0x1ad bytes
>   emacs.exe!__tmainCRTStartup$filt$0()  Line 572 + 0x16 bytes C
>   msvcr100.dll!__C_specific_handler()  + 0x97 bytes
>   ntdll.dll!RtlDecodePointer()  + 0xbd bytes
>   ntdll.dll!RtlUnwindEx()  + 0xbbf bytes
>   ntdll.dll!KiUserExceptionDispatcher()  + 0x2e bytes
>   ntdll.dll!RtlDeNormalizeProcessParams()  + 0x5a4 bytes
>   ntdll.dll!RtlDeNormalizeProcessParams()  + 0x4cb bytes
>   emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
>  Line 642 C
>   emacs.exe!set_alarm()  Line 326 C

IIUC, setitimer is being called recursively here, is that right?  It
looks like some exception happened on line 642 of w32proc.c, that
exception got caught by the (SIGSEGV, I presume) signal handler, and
terminate_due_to_signal was called, which again called setitimer
through totally_unblock_input.  setitimer is certainly not ready to be
called recursively, and that recursion happens inside a critical
section, which is even worse.

Fabrice, can you see what is wrong with the first call to setitimer?
What kind of exception is that, and why does it happen?

Anyway, this all happens when Emacs exits:

>   emacs.exe!do_pending_atimers()  Line 397 C
>   emacs.exe!unblock_input()  Line 7159 C
>   emacs.exe!check_glyph_memory()  Line 2335 C
>   emacs.exe!Fkill_emacs(__int64 arg)  Line 1832 + 0x8a bytes C
>   emacs.exe!Ffuncall(__int64 nargs, __int64 * args)  Line 2773 C

So it's probably some problem with shutting down Emacs, I guess some
cleanup code I added needs some work.  Fabrice, can you see if the
problem goes away if you comment out the 3 lines in term_timers that
delete the critical sections?

Also, what does the timer thread do when this crash happens? is it at
all alive?

FWIW, I see none of this on my system.