[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 21:48:55 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
I just got this (from utimensat, not utimens, but they share a lot of
code) while doing a massively parallel 'make check' of coreutils 8.21 on
Linux 3.7.
The filesystem in question is ext4 atop loopback atop LVM atop md
(raid1), a fairly typical setup for coreutils test runs, I'd think. (The
source tree is ultimately mounted over NFSv3 and gnulib bootstrapped
there, but that shouldn't matter because the first thing I do after that
is cp -a the whole thing into the loopback filesystem and then
configure, build, and test from there.)
#0 0x00007f6bd07858f5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f6bd07858f5 in raise () from /lib/libc.so.6
#1 0x00007f6bd07889fb in __GI_abort () at abort.c:92
#2 0x00000000004021e0 in test_utimens (address@hidden, func=0x401890
<do_utimensat>) at test-utimens.h:35
#3 0x0000000000401449 in main () at test-utimensat.c:86
As before, it's not reproducible on demand (e.g. under a debugger).
- bug#12820: FWIW, this is still happening as of gnulib 4a82904,
Nix <=