So. Were you perchance using it on a Mac? Probably a 64 bit Intel mac? http://gerrit.openafs.org/#change,8132
As nearly as I can tell, this is a very specific problem. The code is fine. The circumstances of building afsd.fuse meant it was collateral damage when we started using roken, but only on MacOS, and probably only for non-32 bit pointers, because MacOS does something odd with dirent.h On Mon, Sep 17, 2012 at 1:20 PM, Derrick Brashear <sha...@gmail.com> wrote: > On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <ho...@hozed.org> wrote: >> I'm looking to get all the low-hanging fruit with unskilled testing. >> Particularly with regressions like this: >> >> hozer@six:~/src/openafs-fuse-git/tests/fuse$ >> /home/hozer/src/openafs-fuse-git/tests/fuse/../../src/afsd/afsd.fuse >> -dynroot -fakestat -d -confdir >> /home/hozer/src/openafs-fuse-git/tests/fuse/conf -cachedir >> /home/hozer/src/openafs-fuse-git/tests/fuse/vcache -mountdir >> /home/hozer/src/openafs-fuse-git/tests/fuse/mntdir >> FUSE library version: 2.8.6 >> nullpath_ok: 0 >> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 >> INIT: 7.17 >> flags=0x0000047b >> max_readahead=0x00020000 >> Starting AFS cache scan...found 0 non-empty cache files (0%). >> afsd: All AFS daemons started. >> Segmentation fault >> >> >> I am pretty sure this is related to the work Simon is doing on Libtool, >> and there's a 90% probability it's a 30-second 'aha', followed by a two >> line fix, and we're back to working again. >> > > I'd bet not. However.... > >> The code is so complicated it will take me half a day to track down what >> that two line fix is, or work in my own isolated fork and not get updates >> as quickly. That unskilled smoke testing and/or automated runs gets a LOT >> of mileage. > > Not really. Build with debugging and get a real backtrace. That said, > since fuse is not *required* > functionality in a build, yes, it's undertested. This is why we've > generally avoided code which doesn't > always build. Or, at least tried to. > >> It also gives people who want to learn about the codebase something simple >> and meaningful they can do, instead of waiting around for someone else to >> come up with a test plan. > >> >> On Mon, Sep 17, 2012 at 11:25:36AM -0500, David Boyes wrote: >>> > How about an effort to get nightly builds of master available on as many >>> > platforms as possible, and getting thousands of bored college students to >>> > download, install, and test them? >>> >>> I think that's still overly optimistic. There's a lot of moving parts here; >>> you just can't just install a package and have it do something useful. You >>> need to have a lot of surrounding infrastructure that involves real control >>> of a fair amount of stuff that random college students won't have. 'make >>> check' on a single machine will never give you useful testing results other >>> than to find packaging or "smoke test" errors, which aren't all that >>> helpful overall. >>> >>> > Wouldn't that massive crowsourced testing effort be worth the time of a >>> > single developer to make sure *some* sort of package, even if it's half- >>> > assed, gets distributed? I can't think of much of anything else that has a >>> > bigger resource multiplation factor than a 'one click install', along >>> > with some >>> > defaults to use a 'test.openafs.org' cell. >>> >>> As others have commented, unskilled testing performed without a detailed >>> test plan on software systems this complex is probably less helpful than >>> might otherwise appear. GIGO applies here. A uncoordinated test process is >>> unlikely to produce anything useful in that there have to be a sequence of >>> coordinated tests, replacing one component at a time in a known order. I >>> can't see how crowdsourcing would help here. >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > > -- > Derrick -- Derrick _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
