Bug 158076 - LD_ASSUME_KERNEL=2.2.5 leads to occasional core dumps of ls
LD_ASSUME_KERNEL=2.2.5 leads to occasional core dumps of ls
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-18 10:13 EDT by Mark van Rossum
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 20:08:27 EDT
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 Mark van Rossum 2005-05-18 10:13:16 EDT
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:
Comment 1 Jakub Jelinek 2005-05-19 05:26:57 EDT
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
Comment 2 Mark van Rossum 2005-05-19 08:46:56 EDT
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
Comment 3 Jakub Jelinek 2005-05-19 09:39:58 EDT
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 11:54:56 EDT
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
Comment 5 Jakub Jelinek 2005-05-19 12:13:12 EDT
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 15:29:52 EDT
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-02 20:08:27 EDT
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.

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