[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12820: FWIW, this is still happening as of gnulib 4a82904
From: |
Nix |
Subject: |
bug#12820: FWIW, this is still happening as of gnulib 4a82904 |
Date: |
Tue, 26 Feb 2013 22:26:20 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
On 26 Feb 2013, Paul Eggert verbalised:
> On 02/26/13 13:48, Nix wrote:
>
>> #2 0x00000000004021e0 in test_utimens (address@hidden, 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)