DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=F8DB/T+QKkBKzLd5
	V9fPiBxuscfmys9AWj74zILk0x9qZJTZYIWcI2uOSn7UwX9aLgzohaVymVOmxVZs
	YaL/kC8sAl2nV4DoG9/Drdae9iAbg90JwKas4ZOV+rvkyQ17YlopxU4uK7s5aOzK
	drAjwipzD+m8+wp+bkmMFW6EqnE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <54216808.7090600@cornell.edu>
Date: Tue, 23 Sep 2014 08:31:04 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: cygwin <cygwin AT cygwin DOT com>
CC: Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: Strange gdb backtraces on 64-bit Cygwin
References: <5419FB60 DOT 5090908 AT cornell DOT edu>
In-Reply-To: <5419FB60.5090908@cornell.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 AT adacore DOT com>
Date:   Mon Sep 2 09:28:02 2013 +0000

     2013-09-02  Tristan Gingold  <gingold AT adacore DOT 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