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.
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.
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.
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?
I will try the different shells and report back.
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.