arla 0.20: getcwd & XFS panics

[Max]

You (Brandon S. Allbery KF8NH) wrote:
> In message <E0ztLNz-0000Ys-00 at chinook.stanford.edu>, Max writes:
> +-----
> | I just compiled Arla 0.20 and noticed some major problems.  The first
> | mistake was copying getcwd.so to /lib.  I did this with all the other
> | versions with no major problems.  My /etc/ld.so.preload has been
> | modified appropriately.  As soon as I overwrote the old getcwd.so, the
> | system started responding to EVERY command with "Segmentation fault".
> +--->8
> 
> You didn't pay attention to the instructions, then.  Overwriting a shared 
> library that's in use is fatal in Linux; the install instructions in the 
> announcement specifically stated that you need to rename the existing 
> getcwd.so, then copy the new one in, so the running copy isn't overwritten.

This was never a problem with the old getcwd, I've been doing this
ever since version 0.14 came out.  I also didn't see any mention of
this in either INSTALL, README, or NEWS.  Where are these instructions
that you are referring to?

> | log in and remove getcwd.so from ld.so.preload.  Until I did that, I
> | couldn't start X (it complained about a missing __getcwd symbol).
> +--->8
> 
> Is your X server (or wrapper) linked against glibc2/libc6 or libc5?  If 
> glibc2, what version?  In glibc-2.0.x, __getcwd is the real getcwd() call; 
> getcwd is a weak symbol, so that it can be redefined in exactly the way the 
> replacement getcwd.so does while leaving the original available.  Or should 
> be.  It's working here (Red Hat 5.2, glibc-2.0.7) but I have no Debian 
> systems to compare against.

The X server is linked against glibc-2.0.7u (or at least it should
be).

> What does "nm --defined-only --dynamic /lib/libc.so.6 | grep getcwd" print?  
> It should be something like:
> 
> 3 at rushlight:1002 B$ nm --defined-only --dynamic /lib/libc.so.6 | grep getcwd
> 00069230 T __getcwd
> 00069230 W getcwd

It produces:

0006a230 T __getcwd
0006a230 W getcwd

Max