Whenever Gaim or some other program crashes, I try to get the stack trace from the "core" file, but it often doesn't work for me. GDB can't recognize the format: dima ~ $ ll core -rw------- 1 dima users 46809088 2006-11-21 16:35 core dima ~ $ file core core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'gaim' dima ~ $ gdb gaim core GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". "/home/dima/core" is not a core dump: File format not recognized (gdb) It happens with other programs, too - dbus-viewer, MATLAB, etc. But it works for some. In particular, when I write my own test cases, GDB understands the core file. I'm using GDB 6.5. The ulimit is set to "unlimited". emerge --info: Portage 2.1.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.18-gentoo i686) ================================================================= System uname: 2.6.18-gentoo i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.6 Last Sync: Tue, 21 Nov 2006 20:01:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://gentoo.noved.org/" LC_ALL="en_US.UTF-8" LINGUAS="en uk ru" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X aac aalib acl acpi aim alsa apache2 asf audiofile bcmath bitmap-fonts browserplugin bzip2 cairo cdparanoia cli cracklib crypt css cups curl dbus dga directfb divx4linux dlloader dri dvd dvdr elibc_glibc emboss encode fam fbcon fbsplash ffmpeg flash foomaticdb gdbm gif glitz glut gpm gstreamer gtk gtk2 hal iconv icq idn imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog javascript jikes jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kernel_linux lcms lesstif libg++ libwww linguas_en linguas_ru linguas_uk live lm_sensors logitech-mouse mad mikmod mmx mng mp3 mpeg mplayer msn mtp musicbrainz ncurses nls nptl nptlonly nsplugin offensive ogg openexr opengl oscar pam pcre pdf pic png povray ppds pppd python qt3 qt4 quicktime rdesktop readline reflection rtc samba scanner sdl session sftplogging slp snmp speex spell spl sse ssl startup-notification subversion svg sysfs tcpd tetex theora tiff timidity truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_ati video_cards_radeon vorbis wifi win32codecs xcomposite xine xinerama xml xorg xscreensaver xv xvid yahoo zeroconf zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This is only getting worse. Since GDB doesn't understand Gaim's cores, I just ran "gdb gaim", and used it like that. Sometime later, both Gaim and GDB exited - no error messages, nothing. Only two core files - one for GDB, the other one for Gaim. This time, GDB understood the Gaim's core file: Core was generated by `/usr/bin/gaim'. Program terminated with signal 5, Trace/breakpoint trap. #0 0xb769fbe1 in __nptl_create_event () from /lib/libpthread.so.0 (gdb) bt #0 0xb769fbe1 in __nptl_create_event () from /lib/libpthread.so.0 #1 0xb76a1237 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0 #2 0xb54c4bd8 in ?? () #3 0xbf9d8f8c in ?? () #4 0xb54c4bd8 in ?? () #5 0x00000014 in ?? () #6 0xb7ee6198 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #7 0x0866da50 in ?? () #8 0x087630d8 in ?? () #9 0x00000000 in ?? () Not sure what happened here... I didn't set any breakpoints. As for the GDB's core - GDB can't understand it, surprisingly...
Yes... I ran "gdb gdb", then started Gaim from there. Now, I actually got a GDB backtrace: dima ~ $ gdb gdb core GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libthread_db.so.1...done. Loaded symbols for /lib/libthread_db.so.1 Failed to read a valid object file image from memory. Core was generated by `/usr/bin/gdb gaim'. Program terminated with signal 11, Segmentation fault. #0 0x08096101 in _initialize_thread_db () (gdb) bt #0 0x08096101 in _initialize_thread_db () #1 0x0809650a in _initialize_thread_db () #2 0x08110b46 in normal_stop () #3 0x08084da0 in discard_cleanups () #4 0x0811bd8a in throw_exception () #5 0x0811be50 in throw_exception () #6 0x0811beac in throw_verror () #7 0x08087c93 in error () #8 0x08087f69 in perror_with_name () #9 0x08094eb5 in supply_gregset () #10 0x0809bb07 in linux_record_stopped_pid () #11 0x08097d6b in _initialize_thread_db () #12 0x0811195f in resume () #13 0x08111b5b in resume () #14 0x08112cc0 in handle_inferior_event () #15 0x0811415c in wait_for_inferior () #16 0x081142e5 in proceed () #17 0x0810f5db in get_inferior_args () #18 0x08084032 in execute_command () #19 0x0811fb68 in push_prompt () #20 0x08120898 in display_gdb_prompt () #21 0x081cb144 in rl_callback_read_char () #22 0x0811fd1b in push_prompt () #23 0x0811f680 in gdb_do_one_event () #24 0x0811eb1b in delete_async_signal_handler () #25 0x0811f2a2 in gdb_do_one_event () #26 0x0811c0b3 in catch_errors () #27 0x080c56a4 in _initialize_tui_interp () #28 0x0811c6ff in current_interp_command_loop () #29 0x0807d33b in gdb_main () #30 0x0811c0b3 in catch_errors () #31 0x0807db0b in gdb_main () #32 0x0811c0b3 in catch_errors () #33 0x0807d321 in gdb_main () #34 0x0807d2e5 in main () Should this be filed as a separate bug, btw?
what version of gdb are you using ? 6.5-r2 ? if so, try re-emerging gdb with USE=vanilla and see if that helps
I am seeing the same problem with gdb-6.6
*** Bug 159785 has been marked as a duplicate of this bug. ***
*** Bug 161147 has been marked as a duplicate of this bug. ***
someone get back to me on the USE=vanilla thing after that, post a core dump that exhibits the problem
Yes, this still happens with vanilla gdb. Here's the program I used: int main() { int *a = 0; *a = 0; return 0; } When I run it, it creates a bad "core" file about 45% of the time. I tested it using this bash script: i=0 x=0 while [ $i -lt 50 ] do ./temp if gdb ./temp core < /dev/null 2>&1 | grep -q 'not a core dump' then let x=x+1 fi let i=i+1 done echo $x
Created attachment 108593 [details] A bad core file
Created attachment 108594 [details] A good core file
Created attachment 108596 [details] The actual executable
Updating to kernel 2.6.20 fixed the problem for me. I was getting 100% bad core files (using the test in comment 5) under 2.6.19. Under 2.6.20, I get none. Tested with gdb-6.6.
i'm hitting this on USE=vanilla gdb-6.6 and a much older kernel as well - 2.6.18-rc5-mm1.
ive seen some mentions that the core dumping would sometimes not work in older kernels if you can reproduce with kernels newer than 2.6.20, re-open please
Bug 159785 is marked as a duplicate of this bug. (Have no idea why). As I've commented before there the bug should be reopened. Stable gentoo-sources on x86 and gdb 6.6-r2 give me the "Failed to read a valid object file image from memory." error.
regardless, the solution seems to be "upgrade your kernel to latest release" ... if it's broken under a certain kernel version but fixed in a newer one, it isnt really a bug in gdb and we dont plan on providing patched kernel sources
(In reply to comment #16) > regardless, the solution seems to be "upgrade your kernel to latest release" > ... if it's broken under a certain kernel version but fixed in a newer one, it > isnt really a bug in gdb and we dont plan on providing patched kernel sources > This is not a gdb problem, but a gentoo one. It seems to me, that if gdb-6.6-r2 has a problem with gentoo-sources 2.6.19, both _cannot_ be marked stable. Either gentoo, marks gentoo-sources 2.6.20 stable in x86 or masks gdb 6.6 until 2.6.20 is marked stable. Is this the more logic thing to do or am I just mad?
we're working on moving the 2.6.20 kernel to stable, but we dont generally track stable packages to the stable kernel ebuilds as it's trivial to install any version of the kernel yourself
(In reply to comment #18) > we're working on moving the 2.6.20 kernel to stable, but we dont generally > track stable packages to the stable kernel ebuilds as it's trivial to install > any version of the kernel yourself > Ok, thank you. I do understand it would be quite hard to track all the stable/unstable deps, etc. But saying that it's trivial to install any version of the kernel is flawed. In Gentoo it's trivial to install any version of any software (if it is already in portage). Cheers... [emerging 2.6.20-r5, If I keep getting problems you'll still hear from me. ;)]
