On 11/07/18 10:05, Paul Eggert wrote: > Thomas Deutschmann wrote: > >> Not sure if this is a kernel problem. Isn't test suite using >> LD_PRELOAD to pull in additional libraries which could cause >> such a breakage? > > You're right, it could be a library problem. The test suite's LD_PRELOAD > library > just returns what the C library gives it, though. Perhaps LD_PRELOAD usage is > messing up malloc on your platform, so that it returns improperly-aligned > pointers? You might try something like the attached patch to see whether the > C > library is doing that. > >> And wouldn't "rm" show any failure during normal use? > > Yes, one would think so. > > In any case, this is not sounding like a bug in coreutils itself.
This could be due to my hack for 32 bit in: https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.25-43-g54c1397 which fails due to the alignment requirement on sparc This is using a 32 bit userland right? We can skip this test on 32 bit, as there really is nothing arch specific that we're testing here. Does this skip the test for you? diff --git a/tests/rm/rm-readdir-fail.sh b/tests/rm/rm-readdir-fail.sh index 75fa339..580d8ec 100755 --- a/tests/rm/rm-readdir-fail.sh +++ b/tests/rm/rm-readdir-fail.sh @@ -27,9 +27,9 @@ mkdir -p dir/notempty || framework_failure_ cat > k.c <<\EOF || framework_failure_ #define _GNU_SOURCE -/* Setup so we don't have to worry about readdir64. */ +/* Avoid having to also handle readdir64. */ #ifndef __LP64__ -# define _FILE_OFFSET_BITS 64 +# error skipping test on 32 bit #endif #include <dlfcn.h>
