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

[John A Meinel]

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/address@hidden/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/address@hidden/patch-log/{arch})
=> ./{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
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