This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 2.4-2.5 x64: bash crashes on backticks, gdb crashes on opening core dump
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin at cygwin dot com
- Cc: Ivan Pozdeev <vano at mail dot mipt dot ru>
- Date: Tue, 22 Mar 2016 09:53:41 +0000
- Subject: Re: 2.4-2.5 x64: bash crashes on backticks, gdb crashes on opening core dump
- Authentication-results: sourceware.org; auth=none
- References: <56EE67C4 dot 1070900 at mail dot mipt dot ru>
- Reply-to: cygwin at cygwin dot com
On 20/03/2016 09:05, Ivan Pozdeev wrote:
gdb
---
I managed to debug the gdb session with VisualGDB (trial).
It turns out, the root cause is that the /bin/sh executable is x64, but
the core file `sh.exe.core' - of the same executable - has i386 format!
(objdump: <...>sh.exe.core: file format elf32-i386)
And gdb doesn't check that. Created ticket (incl. patch):
https://sourceware.org/bugzilla/show_bug.cgi?id=19834
Now I'm stumped. How can this be?! Does this mean `dumper' is faulty?
If this was normal, gdb would likely be able to process the dumps.
summary
-------
Writing this primarily to alert the community of these apparent critical
bugs.
Hints on where to look inside `dumper' would be more than welcome, too.
This is clearly a bug in dumper, which doesn't look like it's been
ported to x86_64. See [1]
Ideally gdb wouldn't crash when presented with such an invalid core dump.
The strangeness which is a cygwin core dump doesn't appear to be
documented anywhere but in the source code of dumper, but it is an elf
file containing the memory image of the dumper process, with elf notes
containing various Win32 API status structures.
[1]
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/utils/dumper.cc;hb=HEAD#l628
--
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