Bug 167202
| Summary: | No core dumps anymore with latest 2.6.12 kernel | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | oll <olivier.lelain> |
| Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | cagney, jan.kratochvil, roland, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | gdb-6.5-15.fc6.i386 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-26 21:40:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 202809 | ||
| Bug Blocks: | |||
|
Description
oll
2005-08-31 14:57:41 UTC
This works fine for me on a similar sounding workstation (Dell Precision 2x Xeon's with HT) with the latest kernel. (20:33:24:davej@delerium:~)$ ps ax | grep gdmgreeter 2461 ? Ss 0:00 /usr/bin/gdmgreeter 10800 pts/1 S+ 0:00 grep gdmgreeter (20:33:29:davej@delerium:~)$ sudo gcore `pidof gdmgreeter` (20:33:35:davej@delerium:~)$ file core.2461 core.2461: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'gdmgreeter' (20:33:56:davej@delerium:~)$ uname -r 2.6.12-1.1378_FC3smp Is this still broken for you ? Sorry, I did a really bad description : I have core dumps, but they are unusable. What's strange is that you don't have this message : "warning: The current VSYSCALL page code requires an existing execuitable. Use "add-symbol-file-from-memory" to load the VSYSCALL page by hand " which is the key of my problem I think I just "yummed" the latest 381 kernel, but with no further success : [olelain@trevezel ~]$ /usr/bin/gdb /usr/bin/xpdf core.7614 GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) .. Failed to read a valid object file image from memory. Core was generated by `/usr/bin/xpdf'. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Cannot access memory at address 0xb7f52000 #0 0xb7f66402 in ?? () It happens with every user with 2.6.12 and only 2.6.12 kernel. They all have a FC3 from scratch. I mean kernel is not rebuild, ans there's no cat "tuning options" in /proc files. This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you. I just try with a freshly installed FC4. I don't have the "warning: svr4_current_sos: Can't read pathname for load map: Input/output error" message anymore but core files still remain unusable. This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. It's the same with FC5-test2 (2.6.15-1.1955) If the report is really about what happens when you use gcore, then that does not have anything to do with the kernel core dump code. gcore is a script that uses gdb's command to create a core file by examining the live process in all the ways gdb normally does that. If the failure mode is from using gcore, then reassign this bug to gdb. If the failure mode is from kernel core dumps, then add to this bug a clear scenario to reproduce the problem. The scenario was in my first post : 1.Run an application : easier to test a non gnome one (because of gnome_segv2) ex: xpdf 2. gcore `pidof xpdf` then : gdb /usr/bin/xpdf core.3192 gives me : warning: current_sos: Can't read pathname for load map: Input/output error Cannot access memory at address 0xb7eff000 #0 0xb7f16402 in ?? () (gdb) bt #0 0xb7f16402 in ?? () Cannot access memory at address 0xbff145bc I don't know if it's X or Y fault but it just happened since the 2.6.12 kernel. I mean , with the same gdb package, it never happened with prior versions of 2.6.12. And it always happens with 2.6.12 and later. This report is about gcore, which is part of gdb. It lacks any information about which gdb rpm it's for. In general kernel+gdb fixed in FC6.
$ rm -f /tmp/core.bash*;bash -c 'sleep 1h;:' & pid=$!; gcore -o /tmp/core.bash
$pid;gdb bash /tmp/core.bash*
[1] 26420
Using host libthread_db library "/lib/libthread_db.so.1".
0x0084b402 in __kernel_vsyscall ()
Saved corefile /tmp/core.bash.26420
GNU gdb Red Hat Linux (6.5-15.fc6rh)
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 "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
...
Core was generated by `/bin/bash'.
#0 0x0084b402 in __kernel_vsyscall ()
(gdb) bt
#0 0x0084b402 in __kernel_vsyscall ()
#1 0x4ce9f7c3 in __waitpid_nocancel () from /lib/libc.so.6
#2 0x08079606 in waitchld (wpid=<value optimized out>, block=0) at jobs.c:2911
#3 0x0807b438 in wait_for (pid=26424) at jobs.c:2290
#4 0x0806ea7a in execute_command_internal (command=0x90d8750, asynchronous=0,
pipe_in=-1, pipe_out=-1,
fds_to_close=0x90f0f80) at execute_cmd.c:722
#5 0x0806f493 in execute_command (command=0x90d8750) at execute_cmd.c:354
#6 0x0806e95e in execute_command_internal (command=0x90f1180, asynchronous=0,
pipe_in=-1, pipe_out=-1,
fds_to_close=0x90f0f70) at execute_cmd.c:1523
#7 0x0809fce1 in parse_and_execute (string=0x90ccf78 "sleep 1h;:",
from_file=0x80cdd60 "-c", flags=4) at evalstring.c:275
#8 0x0805d224 in run_one_command (command=0xbfb09188 "sleep 1h;:") at shell.c:1281
#9 0x0805e130 in main (argc=1, argv=0xbfb082e4, env=0xbfb082f4) at shell.c:663
(gdb) q
|