[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] arch/tla on cygwin (again)

From: John A Meinel
Subject: Re: [Gnu-arch-users] arch/tla on cygwin (again)
Date: Thu, 21 Apr 2005 16:25:51 -0500
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Bob Tanner wrote:

On Friday 15 April 2005 12:26 pm, John Arbash Meinel wrote:

You might try to simulate one of the tests. You can do something like this:
cd $builddir/tla/tests/homedir
export HOME=`pwd`
cd ../workdir
cd <whatever directory tla was running in>
gdb --args <the command that failed>   is the test suite failing.

The 'tla commit' below is what fails.

This is the wrong tla. The problem is that this will be the tla in your
path, and not the newly built one. This may not matter in your case if
you are using the same version, but this should be:
gdb --args ${builddir}/../tla/tla commit -d hw-2 -s ...

 gdb --args tla commit -d hw-2 -s \"Need a changeset\"

tla is an overloaded function in tests/test-framework so that it uses
the correct binary.
I'll continue, as it may not matter, but I wanted to mention it for the

Starting program: /home/tanner/projects/tla-pcomp/src/=build/tla/tla/tla.exe
commit -d hw-2 -s \"Need a changeset\"
PANIC: i/o error in arch_inventory_traversal/is_nested_tree
Program exited with code 02.

Breakpoint 5, is_nested_tree (path=0x1005b180
at /home/tanner/projects/tla-pcomp/src/tla/libarch/invent.c:1008

hackerlab/vu/vu.c:900 vu_lstat
hackerlab/vu/vu.c:494 vu_path_dispatch

I think the problem is here, return &_vu_fs_handlers.nhp[x].handler; shows the
closure to be null.

The closure is pretty much *always* null. I don't know of any vu
handlers that use a non-null closure. So that isn't a bug. The handler
shouldn't be null, but the closure is.

(gdb) p _vu_fs_handlers.nhp[x].handler
$30 = {vtable = 0x4aef80, closure = 0x0}

We pop the stack back into vu_lstat()

return handler->vtable->lstat(errn, path, buf, handler->closure);

Stepping into

hackerlab/vu/vu-pathcompress.c:238 pathcompress_lstat
hackerlab/vu/pathcompress.c:230 pathcompress_compress_path
hackerlab/vu/pathcompress.c:123 pathcompress_process_path
hackerlab/vu/pathcompress.c:46 pathcompress_working_dir
hackerlab/vu/pathcompress.c:109 pathcompress_find_shortname
hackerlab/vu/pathcompress.c:70 pathcompress_find_name

Code is a little convoluted, not sure what it's doing here, but it looks like
the mapping between the compressed filename and the real filename is getting

Well your output from debug was:
=> ./{arch}/HELLO-~1/HELLO-~1/HELLO-~1.0/address@hidden/PATCH-~1/{arch}

Which seems to be a valid compressed path.

Though it might be trying to do something else.
The actual complaint is that vu_lstat returned something other than
exists or ENOENT. (and it should return ENOENT, since you should not
have an {arch} file in the middle of your patch-logs.)

I'm wondering if you are getting something like ENOTDIR, or ENAMETOOLONG

I'm posting a new version that adds a little bit more message before

Also, one thing that I like to do is to "breakpoint panic" when running
under gdb, since tla likes to exit suddenly.
Just a tip to make things easier.

You shouldn't get ENOTDIR, since the only reason it was there is that it
found the "patch-log" directory, and we know it exists because it had a
valid compressed name.
If you are getting ENAMETOOLONG, then I'm not sure what we can do.

Where are you running the tests? It's possible that you are already in a
directory too deep.
C:\Documents and Settings\LongUsername\My
Is pretty long.
And the problem with path compression is that it only compresses the
portion of the path that it sees. So that if you start at 100 chars, you
only have 160 chars for pathcompress to work with.
And I don't think we want to use absolute paths yet, as right now it
involves running the pathcompress on the entire path, and it's already slow.
I always develop in H:\dev, so I don't have a long starting path. I
might try switching my directory to see if I can cause an error, but
there isn't much I can say other than "don't do that". :)

Attached is output from a -DDEBUG compile of make test, hope it helps.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]