I'm playing with Tom Lord's arch revision control system, which for
idiosyncratic reasons likes to create very deep paths.

Attempts to hoard these cause a repeatable crash of venus when
hoarding on my laptop, confirmed by attempting to hoard an ancestor
directory on a separate installation (which crashes in the same way;
no useful backtrace as the libraries and venus were stripped by
debhelper :-( ).  It only seems to happen when hoarding; I can ls
files in the problematic subtrees or cat them, and obviously venus had
no trouble _creating_ them.

The crash actually happens in

#3 vproc::namev(char*, int, venus_cnode*) (this=0x6e656870,
   path=0x150a2bb0 "henstephenstephenstephenstephenstephenstephenstephen\
stephenstephenstephenstephenstephenstephenstephenstephenstephenstephen\
stephenstephenstephenstephenstephenstephens"..., \
flags=352986320, vpp=0x68706574)

(long line broken for readability).  However, pretty obviously memory
is badly corrupted (`this' is actually the string "phen" and `vpp' is
"teph", in little-endian order).  Searching back in memory for the
start of the corruption, I find a bunch of uninterpretable junk,
followed by the string of bytes 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8,
followed by _exactly_ 256 bytes "./Research/.../stephen" (I've elided
the middle), followed by the "stephenstephen..." pattern, which
continues until I get a memory access error.  (The deepest such I know
of in my /coda is actually 288 characters long, including the initial
"./".  I don't know what exactly is being accessed because of the
truncation, and gdb is completely confused so I can't access *this or
*vpp :-(.)

"." is the root volume for my realm.

My guess is that the bug is taking the last path component of a
256-character buffer, and repeatedly appending it to another string in
the heap somewhere.  The reason I suspect this is that I saw the same
thing before, where a truncated final path component was repeated over
and over.  I tried rm -rf'ing that offending path, which was a temporary
scratch directory, and then got the crash again as above.  The last
component above is truncated from "stephen_at_xemacs.org--takezono" (I've
verified that the path I found in memory actually exists in /coda).

I tend to suspect something in hoard is passing bogus paths to the
kernel, which passes them on to venus, because this only happens with
hoarding, and venus handles accessing those paths fine via ls and cat.
However, if so, venus should be checking lengths of strings coming
from client programs somewhere and apparently isn't.

*****

By the way, although the fact that reported method arguments are weird
suggests stack corruption, I don't believe it.  In fact if I print
&this, (char *) flags, and &vpp I get addresses very near `path'
(0x150a2c88, 0x150a24d0, and 0x150a2c94), while the frame addresses
printed in the backtrace above frame #3 are rotations of the bytes of
"stephen" (in little-endian order).

Ie, gdb since pre-6.0 is broken, and seems to regularly get confused
about how many levels of indirection it is dealing with.  I know that
for XEmacs bugs which are repeatable on both Debian Linux and FreeBSD,
my FreeBSD-using colleague (with gdb at 5.x) regularly posts sane
backtraces when the Linux backtrace is obviously bogus (it often
prints ints as though they were pointers, etc.)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.