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 161455 - bash command corrupts shared libraries
Summary: bash command corrupts shared libraries
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-23 15:34 UTC by Stuart MacDonald
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-29 20:15:13 UTC

Attachments (Terms of Use)

Description Stuart MacDonald 2005-06-23 15:34:25 UTC
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:


Steps to Reproduce:
1. See above.
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 16:17:42 UTC
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 16:34:44 UTC
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
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 16:56:49 UTC
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 17:05:51 UTC
I will try the different shells and report back.

Comment 5 Stuart MacDonald 2005-06-29 20:15:13 UTC
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.