Bug 91429

Summary: ls and mkdir commands cause segmentation fault
Product: [Retired] Red Hat Linux Reporter: Need Real Name <johnk>
Component: fileutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
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: 2003-06-02 13:21: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:

Description Need Real Name 2003-05-22 15:38:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
When issuing an ls or mkdir command a segmentation fault results.  All other 
commands seem to be working.  Recently performed up2date on all components.  
Will try booting to an earlier kernel.

Version-Release number of selected component (if applicable):
kernel 2.4.20-13.7

How reproducible:
Always

Steps to Reproduce:
1.ls
2.
3.
    

Actual Results:  segmentation fault

Expected Results:  directory listing

Additional info:

same happens with mkdir command

Comment 1 Tim Waugh 2003-05-22 15:40:19 UTC
See if 'dmesg' says anything interesting.

Comment 2 Need Real Name 2003-05-22 16:00:31 UTC
Dmesg did not produce any clues as to what may be causing this.

Comment 3 Tim Waugh 2003-05-28 09:54:20 UTC
Please show me the output of this command:

rpm -q '%{arch}\n' glibc; uname -a

Comment 4 Need Real Name 2003-05-28 13:39:10 UTC
package %{arch}\n  is not installed
glibc-2.2.4-32

Comment 5 Tim Waugh 2003-05-28 14:47:38 UTC
Sorry, gave the wrong command.  Please try this:

rpm -q --qf '%{arch}\n' glibc
uname -a


Comment 6 Need Real Name 2003-05-28 16:05:45 UTC
result of the above command
i686

Comment 7 Tim Waugh 2003-05-28 16:08:17 UTC
..and 'uname -a'?

Comment 8 Need Real Name 2003-05-28 16:25:04 UTC
rpm -q --qf '%{arch}\n' uname -a produced no result.  Returned to the command 
prompt.

Comment 9 Need Real Name 2003-05-28 16:29:50 UTC
sorry about that <<uname -a>> produced the output
Linux domainname.com 2.4.20-13.7 date....i686 unknown

Comment 10 Tim Waugh 2003-05-29 09:51:24 UTC
Run 'gdb ls' and at the (gdb) prompt type 'r' and press return.  When you get a
segmentation fault, type 'bt' and press return.  What does it say?

Comment 11 Need Real Name 2003-05-29 16:02:20 UTC
#0 0x8503fff in strcpy() at strcpy:-1
#1-#6 same as above with hex shift
#7 0x40044657 in__libc_start_main (main=08x049740<strcpy+568> argc=1, 
ubp_av=0xbfffeee4, init=0x8049060 <_inti>, fini=0x804fcb0 <_fini>, 
rtld_fini=0x4000dcd4 <_dl_fini>,stack_end 0xbfffeedc) 
at ../sysdeps/generic/libc-start.c:129
(gdb)

Comment 12 Tim Waugh 2003-05-29 16:42:06 UTC
Do you get output from this command?:

rpm -V fileutils glibc

Also, did you try booting an earlier kernel?

Comment 13 Need Real Name 2003-06-02 13:05:04 UTC
rpm -V fileutils glibc produced list of executables in /bin directory.
example S.5.... /bin/ls and one listing S.5... T c /etc/profile.d/colorls.sh

Tried an earlier Kernel with the same results.

Comment 14 Tim Waugh 2003-06-02 13:21:27 UTC
'S.5.... /bin/ls' as output is bad news: it means that the ls binary does not
match the one that was installed from the fileutils package.

Sounds like that binary was modified outside of the process of installing RPMs.
 Might want to check your security settings if this machine is on the Internet.

(You could force upgrade the fileutils package to get the right binary back.)