Bug 161455 - bash command corrupts shared libraries
bash command corrupts shared libraries
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-23 11:34 EDT by Stuart MacDonald
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-29 16:15:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stuart MacDonald 2005-06-23 11:34:25 EDT
Description of problem:

I had a FC3 install that this happened on. Yesterday I installed FC4, and this
morning it happened on that too. I've got a linux development machine. FC4,
everything installed. I have a uClinux source tree set up, and the m68k-elf
cross-compile toolchain installed. I want to do a make, and capture the output
to a file for later reference. I do:

# alias fmake
alias fmake='make mrproper oldconfig && make dep all'
# (fmake) > ../fmake.log 2>&1 && (fmake) > /dev/null 2> ../fmake.err.log
# ls
<dir contents snipped>
#

This runs and produces the expected files, one error log to help me quickly
locate errors and one full log to get the error in context. However, sometimes
I get:

# (fmake) > ../fmake.log 2>&1 && (fmake) > /dev/null 2> ../fmake.err.log
# ls
ls: accessing corrupt shared library
#

at which point my system is hosed and I need to reinstall.

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


How reproducible:

Extremely.

Steps to Reproduce:
1. See above.
2.
3.
  
Actual results:

Shared librar[y|ies] [is|are] corrupt. System is unusable.

Expected results:

Some files with output.

Additional info:

I am willing to assist in debugging this issue.
Comment 1 Tim Waugh 2005-06-23 12:17:42 EDT
If you make this project as a non-root user, does the problem still happen?

To be honest, I really don't think this is a bash problem, but much more likely
something that your Makefile is doing.
Comment 2 Stuart MacDonald 2005-06-23 12:34:44 EDT
Perhaps. However;

1: This corrupt libraries problem has never surfaced in the 2.5 years of
uClinux development I've been doing, using the exact same makefile each and
every time.
2: This is the first time I've tried using that much redirection of output
for anything. The fact that the problem correlates with it likely isn't
coincidence.
3: Loading shared libraries is supposed to be a read-only thing, yes? How would
a lowly app have the write capability to corrupt a shared library? My bug-sense
is tingling telling me it's a lower-level issue.

I will give the non-root user angle a try.

I said I was willing to debug, and I meant it. However, each failure results in
a reinstall of the OS, which takes a couple hours. So testing will likely be
slow and limited to weekends when I have some free time.
Comment 3 Tim Waugh 2005-06-23 12:56:49 EDT
Running a command as root can write to anything, in general.  Try running your
command as a non-root user and see if it still happens.

One way to isolate the shell from this is to try a different one -- does the
same thing happen in tcsh or zsh, for instance?
Comment 4 Stuart MacDonald 2005-06-23 13:05:51 EDT
I will try the different shells and report back.
Comment 5 Stuart MacDonald 2005-06-29 16:15:13 EDT
A full check of the source code revealed a typo had crept in the Makefile in
the lib directory in uClinux. So instead of
$(STRIP) $(ROMFSDIR)/lib/*
it was
$(STRIP) $(RONFSDIR)/lib/*
which resolved to
m68k-elf-strip /lib/*
which was destroying my libraries.

This is not a bash bug after all. Sorry for the inconvenience.

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