0005232: gdb can't read core file

Notes
(0011046) brianvandenberg (reporter) 2015-09-03 19:30	We're seeing the same issue with gdb 7.7. The most recent version available through opencsw is 7.9, but I don't have permissions to install packages in our environment. I managed to get 7.10 to build with the following config parameters: (...)/configure --prefix=/the/install/path --without-python --disable-largefile --without-system-readline --enable-64-bit-bfd --enable-tui --with-curses --with-expat --with-x --with-libexpat-prefix=/opt/csw Now I can open coredumps that were previously not openable. I've tested in various versions of gdb that I didn't build. 6.8 works fine, but all of the 7.x versions I tested prior to 7.10 were failing (7.2, 7.6, 7.7) in the same manner. Unfortunately, I don't know how any of those builds were produced. At this point, I don't know whether this is a problem that was fixed between 7.7 and 7.10, or building with just the right flags fixed it. Someone reported the same problem to the gdb folks back in 2012, but they didn't have anyone with solaris that could work on it so the issue was never worked. Initially I had tried to configure 7.10 without any extra flags, but it needed --disable-largefile otherwise a build failure occurred. One suspicion I had was earlier versions were perhaps built without that flag (or one of the others I lifted from the csw makefile) and the build wasn't failing at that time like it does with 7.10.

(0011047) pfelecan (manager) 2015-09-04 10:55	Thank you for this information. Packaging gdb 7.10 is on the top of the to do stack. I let you know when there is a new package.

(0011048) pfelecan (manager) 2015-09-04 19:48	There is a new package in unstable, gdb-7.10,REV=2015.09.04. Let me know if this solves your issues.

(0011049) pfelecan (manager) 2015-09-05 11:42	The issue manifests itself on x86 platforms, in the 64 bit variant; on 32 bit variant it works correctly: 32 bit: /opt/csw/bin/pentium_pro/gdb tgdb core GNU gdb (GDB) 7.10 [..] Reading symbols from tgdb...done. [New LWP 1] [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Core was generated by `./tgdb core'. Program terminated with signal SIGABRT, Aborted. #0 0xfeefc0b5 in _lwp_kill () from /lib/libc.so.1 [Current thread is 2 (Thread 1 (LWP 1))] (gdb) bt #0 0xfeefc0b5 in _lwp_kill () from /lib/libc.so.1 0000001 0xfeef6f39 in thr_kill () from /lib/libc.so.1 0000002 0xfeea3603 in raise () from /lib/libc.so.1 0000003 0xfee82961 in abort () from /lib/libc.so.1 0000004 0x08050c46 in main (argc=2, argv=0x8047c54 ",}\004\b3}\004\b") at tgdb.c:9 64 bit /opt/csw/bin/amd64/gdb tgdb core Exception caught while booting Guile. Error in function "make_objcode_from_file": bad header on object file: "GOOF----LE-4-2.0" /opt/csw/bin/amd64/gdb: warning: Could not complete Guile gdb module initialization from: /opt/csw/share/gdb/guile/gdb/boot.scm. Limited Guile support is available. Suggest passing --data-directory=/path/to/gdb/data-directory. GNU gdb (GDB) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> [^] This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-pc-solaris2.10". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. [^] Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. [^] For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from tgdb...done. warning: Couldn't find general-purpose registers in core file. [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Core was generated by `./tgdb core'. warning: Couldn't find general-purpose registers in core file. #0 <unavailable> in ?? () [Current thread is 1 (process 1 )] (gdb) bt #0 <unavailable> in ?? () Backtrace stopped: not enough registers or memory available to unwind further in addition, there is a Guile issue; nominal given that there is no robust 64 bit variant for it in our stack. I suppose that on SPARC we have the same issue.

(0011050) pfelecan (manager) 2015-09-05 12:28	In fact, at least on x86, you cannot mix architectures, i.e., the 32 bit gdb can obtain a stack trace for 32 bit binaries and, a 64 bit gdb can gather the stack trace of a 64 bit binary; the reverse is not working. Possibly a wrapper around gdb can do the discrimination and choose the correct debugger according to the binary to be debugged. For the moment, explicitly using the corresponding debugger is a work around, e.g. : /opt/csw/bin/pentiumpro/gdb 32BitBinary and, /opt/csw/bin/amd64 64BitBinary. HTH. If someone writes such a wrapper I will include it in the package.

(0011051) pfelecan (manager) 2015-09-05 20:09	On a SPARC architecture, the only valid combination of architecture and debugger is the 64 bit gdb, located in /opt/csw/bin/sparcv9/gdb, on a 64 bit binary. Any other combination doesn't work.

Relationships

OpenCSW Bug Tracker