Bug 19834 - crash or "Assertion `core_vec' failed" if core arch is i386 while executable x64
Summary: crash or "Assertion `core_vec' failed" if core arch is i386 while executable x64
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: corefiles (show other bugs)
Version: 7.10
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-17 06:38 UTC by Ivan Pozdeev
Modified: 2016-03-17 14:10 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
fix-untested (523 bytes, application/mbox)
2016-03-17 06:38 UTC, Ivan Pozdeev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Pozdeev 2016-03-17 06:38:19 UTC
Created attachment 9105 [details]
fix-untested

Due to some Cygwin bug, core files created by my Cygwin x64's `dumper' have elf32-i386 format.

The problem is, gdb doesn't do this sanity check, and version 7.9.1 reports "Assertion `core_vec' failed" (analysis follows) while version 7.10.1 crashes straight.

(version 7.9.1) gdbarch_iterate_over_regset_sections_p() returns true for i386 (core_gdbarch) but false for x64 (thread's gdbarch).
So core_vec=sniff_core_bfd() yields NULL but in get_core_registers(), get_core_register_section() is called anyway.

AFAICS, this needs to be checked in corefile.c:validate_files() - bailing out with error.
Can't test the patch 'cuz my bash is half-broken (I was diagnosing that when I run into this error).
Comment 1 Pedro Alves 2016-03-17 10:59:32 UTC
I believe architectures may be different, but compatible, so I don't think the check is right.  But if extending the bfd arch checks is necessary, then it sounds like they should be done _in_ core_file_matches_executable_p, not before it.

BTW, 7.10.1 included a fix for what sounds like the opposite issue:

  https://sourceware.org/ml/gdb-patches/2015-01/msg00198.html
Comment 2 Ivan Pozdeev 2016-03-17 13:14:58 UTC
A core file is a faithful representation of the executable - its state at the moment of crash. How can its architecture possibly be different?
All in all, for all purposes, this looks like a sure tell that the core doesn't match the file so there's no use in going on anyway - the results would be meaningless.

I considered core_file_matches_executable_p() and rejected it because its failure only results in a (not seriously sounding) warning while this is a critical error. If the subroutine can call error() or something itself without breaking the design, I have no objections.
Comment 3 Ivan Pozdeev 2016-03-17 13:22:38 UTC
The patch linked to from comment 1, is not an "opposite" fix but an analogous one - handling an incorrect/malformed core file. The difference is, in that case, it's still possible to continue, but in this one, it apparently isn't.
Comment 4 Pedro Alves 2016-03-17 13:33:11 UTC
Sure.

> Due to some Cygwin bug, core files created by my Cygwin x64's `dumper' have elf32-i386 format.

vs 

> In that particular case the prstatus of an i386 core file looks like that from an AMD64 core file, i.e., it is larger than GDB would expect.

Or said another way:

 64-bit core is broken and has 32-bit format.
vs 
 32-bit core is broken and has 64-bit format.

Thus my "opposite".
Comment 5 Pedro Alves 2016-03-17 14:10:30 UTC
> A core file is a faithful representation of the executable - its state at
> the moment of crash. How can its architecture possibly be different?

"architecture" is an overloaded word, and I didn't realize you are comparing the enum bfd_architecture field.  A (full) BFD architecture carries more info than the machine architecture.  The core may say "I'm ARM", but the executable say "I'm ARM, actually machine FOO, with foo ABI, and I have these extra registers/features."

In any case, for an example of a different, but compatible enum bfd_architecture, see bfd_arch_get_compatible and:

/* The common PowerPC architecture is compatible with the RS/6000.  */

static const bfd_arch_info_type *
powerpc_compatible (const bfd_arch_info_type *a,
		    const bfd_arch_info_type *b)
{

I don't know if these can appear in exec vs core scenarios.

There's also the case of known vs bfd_arch_unknown/bfd_arch_obscure.