Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

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: kernelAssignee: Ingo Molnar <mingo>
Status: CLOSED CANTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: davej, riel, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
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:

Description Mark van Rossum 2005-05-18 14:13:16 UTC
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
setenv LD_ASSUME_KERNEL 2.2.5
and then run 'ls', I get occasional(!) core dumps.

You can also run
@ x = 1
while ($x < 1000)
        ls > /dev/null
        @ x ++

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):

How reproducible:

Steps to Reproduce:

Additional info:

Comment 1 Jakub Jelinek 2005-05-19 09:26:57 UTC
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
info regs

Comment 2 Mark van Rossum 2005-05-19 12:46:56 UTC
(Should I uninstall the non-debug versions ??)

gdb output:
#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,
    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

Otherwise (when the bug does not occur) /lib/i686/ is used.
and the same is true for some other libs.


Comment 3 Jakub Jelinek 2005-05-19 13:39:58 UTC
Can you reproduce the failures even without LD_ASSUME=2.2.5, but with
ulimit -s 2048 instead?

Comment 4 Mark van Rossum 2005-05-19 15:54:56 UTC
With ulimit -s 2048 cores are also dumped.

#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

Comment 5 Jakub Jelinek 2005-05-19 16:13:12 UTC
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...

Comment 6 Dave Jones 2005-07-15 19:29:52 UTC
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.

Comment 7 Dave Jones 2005-10-03 00:08:27 UTC
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.