Bug 158076
| Summary: | LD_ASSUME_KERNEL=2.2.5 leads to occasional core dumps of ls | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark van Rossum <mvanross> |
| Component: | kernel | Assignee: | Ingo Molnar <mingo> |
| Status: | CLOSED CANTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | davej, riel, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-03 00:08:27 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: | |||
I can't reproduce this. Please ulimit -c unlimited, wait until you get a core, then install glibc-debuginfo-2*.i686.rpm (assuming you have glibc-2*.i686.rpm installed), glibc-debuginfo-common-2*.i386.rpm and coreutils-debuginfo-*.i386.rpm (all with matching version-release to the packages you have installed) and gdb /bin/ls core.NNNNN and in gdb bt info regs Using:
glibc-debuginfo-2.3.5-0.fc3.1.i686.rpm
glibc-debuginfo-common-2.3.5-0.fc3.1.i386.rpm
coreutils-debuginfo-5.2.1-31.i386.rpm
(Should I uninstall the non-debug versions ??)
gdb output:
bt
#0 quote_name (out=Cannot access memory at address 0xbfdfd190
) at ls.c:3400
#1 0x0804c6f3 in print_name_with_quoting (
p=0x894eb78 "glibc-debuginfo-2.3.5-0.fc3.1.i686.rpm", mode=143977336, linkok=0,
stat_failed=0, stack=0x0) at ls.c:3572
#2 0x0804c908 in print_file_name_and_frills (f=0x894f3f0) at ls.c:3612
#3 0x0804dd00 in print_current_files () at ls.c:2996
#4 0x0804e808 in print_dir (name=0x894eb18 ".", realname=0x0) at ls.c:2321
#5 0x0804fb4a in main (argc=2, argv=0xbfe00d74) at ls.c:1230
#6 0x44b272d1 in __libc_start_main (main=0x804ea61 <main>, argc=1153668992,
ubp_av=0xbfe00d74, init=0x80578c8 <__libc_csu_init>, fini=0xbfe00d80,
rtld_fini=0,
stack_end=0xbfe00d6c) at ../sysdeps/generic/libc-start.c:237
#7 0x08049da1 in _start ()
(gdb) info reg
eax 0x44c39780 1153668992
ecx 0x0 0
edx 0x894eb78 143977336
ebx 0x805c5b4 134596020
esp 0xbfdfd150 0xbfdfd150
ebp 0xbfdff1b8 0xbfdff1b8
esi 0xbfdfd1a0 -1075850848
edi 0x894eb78 143977336
eip 0x804c273 0x804c273
eflags 0x210286 2163334
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x0 0
Doing 'strace ls', I find that with LD_ASSUME=2.2.5, ls uses
/lib/librt.so.1
Otherwise (when the bug does not occur) /lib/i686/librt.so.1 is used.
and the same is true for some other libs.
/lib/librt.so.1
Can you reproduce the failures even without LD_ASSUME=2.2.5, but with ulimit -s 2048 instead? With ulimit -s 2048 cores are also dumped. bt #0 0x44afade9 in ?? () Cannot access memory at address 0xbfdffffc (gdb) info reg eax 0x805cbf1 134597617 ecx 0x0 0 edx 0xffffffff -1 ebx 0x44b09fb4 1152425908 esp 0xbfdffffc 0xbfdffffc ebp 0xbfe00088 0xbfe00088 esi 0x44b0a6d4 1152427732 edi 0x44b063ef 1152410607 eip 0x44afade9 0x44afade9 eflags 0x210287 2163335 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 Then that sounds like kernel bug, where stack randomization (which is up to 2MB) is still accounted into RLIMIT_STACK. I thought this had been fixed already... An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; Linux i686; U; en) Opera 8.0 Description of problem: If I do (in tsch) setenv LD_ASSUME_KERNEL 2.3.5 or setenv LD_ASSUME_KERNEL 2.2.5 and then run 'ls', I get occasional(!) core dumps. You can also run #!/bin/csh @ x = 1 while ($x < 1000) ls > /dev/null @ x ++ end I do not understand enough about it to understand how this all interacts.. It is a clean, but updated, FC3 install. The randomness and the lack of any useful error message, made it take long to figure out. Similar problems also effect some python programs. Version-Release number of selected component (if applicable): glibc-2.3.5-0.fc3.1 How reproducible: Sometimes Steps to Reproduce: 1. 2. 3. Additional info: