Bug 167202 - No core dumps anymore with latest 2.6.12 kernel
No core dumps anymore with latest 2.6.12 kernel
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
:
Depends On: 202809
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-31 10:57 EDT by oll
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
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 16:40:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description oll 2005-08-31 10:57:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
Since I updated the official kernel package, I can't have core dumps anymore.

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1376_FC3

How reproducible:
Always

Steps to Reproduce:
1.Run an application : easier to test a non gnome one (because of gnome_segv2)
ex: xpdf

2. gcore `pidof xpdf`


  

Actual Results:  I have :

warning: The current VSYSCALL page code requires an existing execuitable.
Use "add-symbol-file-from-memory" to load the VSYSCALL page by hand

Expected Results:  core dump generated

Additional info:

I just did a :
yum update kernel-smp 

on a Dell hyperthread pentium stations.

It was working like a charm with former 2.10 kernels.(maybe 2.6.11 too, I don't know)

It happens with all our (yum) updated stations.
It does not work better with ulimit -c unlimited
Bug-buddy (gnome_segv2) generates now  stupid bt.

This is really annoying since my users are all developpers and they can't work anymore !!

BTW : selinux is disabled
Comment 1 Dave Jones 2005-10-27 20:59:04 EDT
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 ?
Comment 2 oll 2005-10-28 03:45:26 EDT
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.
Comment 3 Dave Jones 2006-01-16 17:13:29 EST
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.
Comment 4 oll 2006-01-17 03:35:41 EST
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.
Comment 5 Dave Jones 2006-02-03 00:55:07 EST
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.
Comment 6 oll 2006-02-20 09:11:44 EST
It's the same with FC5-test2 (2.6.15-1.1955)
Comment 8 Roland McGrath 2006-02-21 20:38:42 EST
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.
Comment 9 oll 2006-02-22 03:19:35 EST
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.
Comment 10 Roland McGrath 2006-02-22 05:20:35 EST
This report is about gcore, which is part of gdb.
It lacks any information about which gdb rpm it's for.
Comment 13 Jan Kratochvil 2007-01-26 16:40:46 EST
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

Note You need to log in before you can comment on or make changes to this bug.