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>
test-get-changeset.sh 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 future.
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 "./{arch}/hello-world/hello-world--mainline/hello-world--mainline--1.0/[EMAIL PROTECTED]/patch-log") 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 corrupted.
Well your output from debug was:
pathcompress_compress_path(./{arch}/hello-world/hello-world--mainline/hello-world--mainline--1.0/[EMAIL
PROTECTED]/patch-log/{arch})
=> ./{arch}/HELLO-~1/HELLO-~1/HELLO-~1.0/[EMAIL PROTECTED]/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 panicing.
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 Documents\MyDevelopment\tla--pcomp--1.3.1\... 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.
John =:->
signature.asc
Description: OpenPGP digital signature_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
