Re: Strange gdb backtraces on 64-bit Cygwin

[Ken Brown <kbrown@cornell.edu>]

On 9/17/2014 5:21 PM, Ken Brown wrote:
> There have been many bug reports involving crashes or assertion failures
> in emacs-X11 or emacs-w32 on 64-bit Cygwin.  Many of these reports
> include gdb backtraces that don't make sense.  The one I'm looking at
> right now is emacs bug#17753.  I'll try to make this email
> self-contained, but anyone interested in the context should start at
>
>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17753#47
>
> The situation in that bug report is that a gdb backtrace showed a call
> to the emacs function "run_timers" in Thread 2, which shouldn't happen.
>   (It should only be called in the main thread.)  There was speculation
> as to whether this could be the cause of the crash.  An alternative
> theory is that the gdb backtrace is bogus.  I'm pretty sure that the OP
> (Markus) was running gdb-7.6.50-4.  His report was about emacs-X11, but
> I've observed similar backtraces for emacs-w32.
>
> To try to sort this out, I've done the following experiment: I've run
> emacs-w32 under gdb with a breakpoint at run_timers.  I've done this on
> both 32-bit Cygwin and 64-bit Cygwin [*], using both gdb-7.6.50-4 and
> gdb-7.8.  [For the latter I used my own build, since the bugfix we
> discussed in a different thread hasn't yet made it into the Cygwin
> distro.]  Transcripts of the four gdb sessions are attached; the file
> names indicate the gdb version and the platform.
>
> My reading of these transcripts is that gdb-7.6.50-4 on 64-bit Cygwin is
> the outlier, and the strange occurrence of run_timers in Thread 2 is
> therefore likely to be a result of a gdb bug.  But it would be great if
> someone familiar with recent gdb development could shed some light on
> this.  In particular, is it plausible that there was a bug of this
> nature in gdb-7.6 that affected only the 64-bit platform and that has
> since been fixed?

I bisected the binutils-gdb repository and found that the strange 
backtrace stopped after the following commit:

commit 9058cc3a1bbf4c43a484120290e4245622782bb0
Author: Tristan Gingold <gingold@adacore.com>
Date:   Mon Sep 2 09:28:02 2013 +0000

     2013-09-02  Tristan Gingold  <gingold@adacore.com>

         * NEWS: Add entry mentioning support for native Windows x64
         SEH data.

         * amd64-windows-tdep.c: #include "objfiles.h", "frame-unwind.h",
         "coff/internal.h", "coff/i386.h", "coff/pe.h" and "libcoff.h".
         (struct amd64_windows_frame_cache): New struct.
         (amd64_windows_w2gdb_regnum): New global.
         (pc_in_range, amd64_windows_frame_decode_epilogue)
         (amd64_windows_frame_decode_insns, amd64_windows_find_unwind_info)
         (amd64_windows_frame_cache, amd64_windows_frame_prev_register)
         (amd64_windows_frame_this_id): New functions.
         (amd64_windows_frame_unwind): New static global.
         (amd64_windows_skip_prologue): New function.
         (amd64_windows_init_abi): Call frame_unwind_prepend_unwinder
         with amd64_windows_frame_unwind. Call set_gdbarch_skip_prologue
         with amd64_windows_skip_prologue.

So I think it's pretty clear that the strange backtrace I observed with 
gdb-7.6.50-4 on 64-bit Cygwin was indeed due to a deficiency in gdb.

I hope that people who have been experiencing emacs crashes with 
"impossible" backtraces will update to gdb-7.8-2.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple