On 26 Feb 2013, Paul Eggert verbalised: > On 02/26/13 13:48, Nix wrote: > >> #2 0x00000000004021e0 in test_utimens (print=print@entry=true, >> func=0x401890 <do_utimensat>) at test-utimens.h:35 > > If that line number is right, the test program > did a creat (file, 0600) that succeeded, followed > by a stat (file, &st) that failed. Offhand the only > way I can see that happening, other than a bug in > the underlying system or a weird resource failure > or some other process mucking things up, is if > you're running a 32-bit application and the file > system assigned a big inode number to the file, so > large that it won't fit in 32 bits. Is that possible?
Nope, this was a 64-bit build. It's mysterious to me as well. A bug in the underlying system is not beyond the bounds of possibility! I'll run the gnulib parallel tests in a tight loop overnight, in the same environment, and see if I can make it happen again. If it can, it's time to figure out how to reproduce it under gdb: I guess running the gnulib tests in a tight loop and then running this test in a tight loop under gdb until it dies might work. -- NULL && (void)
