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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 1 Oct 2012 03:36:39 +0200
> Cc: fabrice.popineau@supelec.fr
> 
> Compiling current trunk on Windows with optimization gives me an unusable exe.

Sorry about that.  The looming feature freeze deadline and the flood
of commits it triggered surely didn't facilitate careful testing of
each changeset before committing.

> Compiler: MinGW GCC 4.6.2
> Compilation options: -march=core2 -fno-omit-frame-pointer -O2
> 
> It either crashes immediately upon starting, or displays an error,
> usually "Wrong type argument, lisp <some number>".

I've just bootstrapped today's trunk with an optimized build and saw
no problems at all.  Not one.  Of course, I use an ancient version of
GCC.  Also, this is a 32-bit Windows XP, while both you and Fabrice
probably run a 64-bit Windows 7.  But still, this means the bugs are
probably very subtle, or even OS version-dependent.

First, do you still see problems if you build with the default
optimization flags, those set by running 'configure' without any
"--cflags" options except those required to pick up your include
directories and image libraries?  In my case, a typical compilation
command line looks like this:

  gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Id:/usr/include/libxml2 
-Demacs=1 -I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o 
oo-spd/i386/gmalloc.o gmalloc.c

IOW, the only GCC switches pertinent to optimizations are

   -gdwarf-2 -g3  -mtune=pentium4 -O2

What happens if you build Emacs like this?

> The crashes disappear if I remove revnos 110296 and 110297.

To be absolutely sure the crashes have nothing to do with the timers
introduced in revision 110287, can you please try this:

  . comment out the line that defines HAVE_SETITIMER in nt/config.nt
  . ifdef away the entire body of 'alarm' (in w32proc.c), except its
    last line, which returns to the caller the value of its argument
  . build Emacs and see if the crashes go away

> In one case, I got  "Wrong type argument: listp, #<EMACS BUG: INVALID
> DATATYPE (PVEC 0x5f000100) Save your buffers immediately and please
> report this bug>", followed by this crash:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
> 5492      VECTOR_MARK (ptr);            /* Else mark it.  */
> (gdb) bt
> #0  0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
> #1  0x0100fbca in mark_maybe_object (obj=61397630) at alloc.c:4216

Can you show backtrace from the other threads, whenever you see a
crash?  I'm specifically interested in the timer thread, it should be
running the timer_loop function.  Is that thread perhaps in the same
place when the crash happens?

> In a debug build, with NO optimizations and no special compilation
> options (no -march) except the ones related to debugging, I get also
> problems but much less frequently. Bootstrapping crashed twice while
> bytecompiling some files, and also while dumping. Restarting the build
> process finished dumping correctly and the resulting exe apparently
> does not crash.

Can you try obtaining backtraces from those crashes of an unoptimized
build?

> A few more backtraces (from the optimized build):
>
> #5  0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
> #6  0x0111b8f2 in add_to_log (format=0x147169c "Error during
> redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
> xdisp.c:9302
> #7  0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
> args=0x88e6b0) at xdisp.c:2424
> #8  0x01012b5a in internal_condition_case_n (bfun=0x1014440
> <Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
>     hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
> #9  0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
> #10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
> #11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
> #12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
> field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
> xdisp.c:20762

This is the display engine trying to report some error that happened
during display of the mode line.  Can you show the values of arg1 and
arg2 in frame #6, which is a call to add_to_log?

> Program received signal SIGSEGV, Segmentation fault.
> 0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
> function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
>     at intervals.c:264
> 264           traverse_intervals (tree->left, position, function, arg);
> (gdb) bt
> #0  0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
> function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
>     at intervals.c:264
> #1  0x0109515a in print_prune_string_charset (string=50344505) at print.c:1295
> #2  print_object (obj=50344505, printcharfun=57538610, escapeflag=1)
> at print.c:1404
> #3  0x010987ac in Fprin1 (object=50344505, printcharfun=57538610) at 
> print.c:560
> #4  0x01098d3f in print_error_message (data=<optimized out>,
> stream=57538610, context=0x88fca7 "", caller=59742426) at print.c:915
> #5  0x0105e419 in cmd_error_internal (data=61397630, context=0x88fca7
> "") at keyboard.c:1124
> #6  0x0105e55e in cmd_error (data=61397630) at keyboard.c:1055
> #7  0x010128ac in internal_condition_case (bfun=0x105c690
> <top_level_2>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
> eval.c:1278
> #8  0x0105cad0 in top_level_1 (ignore=57538586) at keyboard.c:1196
> #9  0x010127c8 in internal_catch (tag=57579026, func=0x105ca70
> <top_level_1>, arg=57538586) at eval.c:1059
> #10 0x0105de5c in command_loop () at keyboard.c:1151
> #11 recursive_edit_1 () at keyboard.c:779
> #12 0x0105e1da in Frecursive_edit () at keyboard.c:843
> #13 0x012432f9 in main (argc=<optimized out>, argv=0x982ec8) at emacs.c:1525

Here, too, some error happened, and cmd_error is called to report it.
Can you show the value of 'data' in frame #6?

Please note that it is not safe to use 'pp' to display Lisp data
structures in a session badly crashed such as these.  You will have to
fall back on 'xtype' and 'xFOO' commands instead, let me know if you
need guidance in using them.

> #1  0x0100a527 in die (
>     msg=0x145e14c "assertion failed: STRINGP (((((((enum Lisp_Type)
> (((obj)) & TYPEMASK)) == Lisp_Symbol)) || suppress_checking ? (void) 0
> : die (\"as
> sertion failed: \" \"SYMBOLP (obj)\", \"print.c\", 1511)), (struct
> Lisp_Sym"..., file=0x145d864 "print.c", line=1511) at alloc.c:6445
> #2  0x01097105 in print_object (obj=<optimized out>,
> printcharfun=57538586, escapeflag=1) at print.c:1511
> #3  0x01095826 in print_object (obj=61404422, printcharfun=57538586,
> escapeflag=1) at print.c:1669
> #4  0x0109813a in Fprin1_to_string (object=61404406,
> noescape=57538586) at print.c:603
> #5  0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
> #6  0x0111b8f2 in add_to_log (format=0x147169c "Error during
> redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
> xdisp.c:9302
> #7  0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
> args=0x88e6b0) at xdisp.c:2424
> #8  0x01012b5a in internal_condition_case_n (bfun=0x1014440
> <Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
>     hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
> #9  0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
> #10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
> #11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
> #12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
> field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
> xdisp.c:20762

Again, a crash during display of mode line, triggered by some error in
redisplay.  Can you show arg1 and arg2 in frame #6?