This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange gdb backtraces on 64-bit Cygwin


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]