On Thu, Dec 11, 2003 at 12:12:40PM +0900, Stephen J. Turnbull wrote:
> I'm playing with Tom Lord's arch revision control system, which for
> idiosyncratic reasons likes to create very deep paths.

Looked at that as well, but I have some 'questions' about the usability
of the locking scheme when a new changeset is committed. There is some
really nasty sequence of cross-directory renames that will not resolve
using the current per-directory operation logs on replicated volumes.

> 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 :-(.)

Interesting, there is a CODA_MAXPATHLEN, which should limit the total
size of an allowed path and is 1024. Then there is CODA_MAXNAMLEN which
limits the size of each path component and is defined as 255.

Maybe some code is allocates a CODA_MAXNAMLEN sized buffer and tries to
store the path in there.

> 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

Looking at the hoard pioctls, there does seem to be some confusion
between CODA_MAXPATHLEN and MAXPATHLEN. Adding a hoard entry only allows
1024 character length pathnames, but deleting can be done with 4096
characters.

> 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.)

It looks like the -O2 optimization is actually more effectively
allocating variables in registers on gcc-3.2+ compilers. Once a
variable is not going to be referenced, it is almost immediately
clobbered if you examine it with gdb.

Jan