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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 01 Oct 2012 10:12:45 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, 12544@debbugs.gnu.org
> 
> > From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> > Date: Mon, 1 Oct 2012 09:31:14 +0200
> > Cc: 12544@debbugs.gnu.org
> > 
> > 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?

I think I fixed this in trunk revision 110318.  The problem was that
the call to term_ntproc, as part of shutting down Emacs, deleted the
critical sections used by the timer threads and by setitimer, so any
call to setitimer after that would use an invalid critical section
object.  I now make sure any calls to setitimer after deleting the
critical sections will return immediately without doing anything.

Juanma, please see if your crashes still persist.  I don't expect them
to disappear, but who knows...