From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17390 invoked by alias); 23 Sep 2014 12:31:24 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 17381 invoked by uid 89); 23 Sep 2014 12:31:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock01.mail.cornell.edu Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.13.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Sep 2014 12:31:22 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s8NCVJfj009578; Tue, 23 Sep 2014 08:31:19 -0400 Received: from [192.168.1.8] (cpe-67-249-176-226.twcny.res.rr.com [67.249.176.226]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s8NCVGoC021644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Sep 2014 08:31:17 -0400 Message-ID: <54216808.7090600@cornell.edu> Date: Tue, 23 Sep 2014 12:47:00 -0000 From: Ken Brown 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 CC: Eli Zaretskii Subject: Re: Strange gdb backtraces on 64-bit Cygwin References: <5419FB60.5090908@cornell.edu> In-Reply-To: <5419FB60.5090908@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00341.txt.bz2 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 Date: Mon Sep 2 09:28:02 2013 +0000 2013-09-02 Tristan Gingold * 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