Current unexplained failures
I sent this to the LSB-si developer list, but not here.
Of course any suggestions (including where I can find
an LSB-conforming ia64 kernel!) are welcome.
========================================
LSB-si/ia32:
Anthony Towns' changes to mprotect also clear the
hang I was seeing, leaving:
Total failures: 1
T.msync 7 claims that the sequence: mmap 1 page,
msync 2 pages at address returned by mmap does not
fail when it should. This is one that behaves
as the test expects on the same system running
natively, and could be either a library change
(which I can't spot) or another test-interaction
problem like the mprotect test was (I can't spot
that, either).
========================================
LSB-si/ia64:
10 unexplained fails, which follow with some analysis.
All other problems have either an unofficial fix, or
at least an explanation such as needing the right
config file value (which I may not actually know yet).
It's possible that some of these cannot easily be
converted into pass, for example, the readv/writev tests
attempt to test overflow of an ssize_t and pick up a
bad value from the system headers; but the algorithm,
if it got the right value, would require constructing an
array of 1024 iovectors with size 9,007,199,254,742,016
bytes each. I actually tried this, and it works for the
readv test (no data is transferred), but the writev test
has to allocate space for at least one of those, and
strangely enough the malloc didn't work.... (grin)
A few of the fixes match accepted TSD (Test Suite
Deficiency) rulings, but this is not true for all.
Some PRs are pending; some are an informal status,
not filed yet but being researched.
The 10 fails:
dlopen 4, 12 (2 fails total), appears that dlopen
(0, RTLD_NOW) does not give access to the binary's
own symbols. This might be a linker flag, but adding
it didn't seem to help; it might be a problem actually
in the libc dlopen code or the dynamic linker, I
see there have been lots of changes to this codebase
in the glibc cvs.
utime 4, 7, 11 (3 fails total), error return is EPERM
on several tests where this is not expected. On 4 and
7 there's an EPERM where no error is expected, on
11 the fail is EPERM instead of expected EACCES.
read and readv test 13 (2 fails total) - atime not
updated when it was expected to. This is *not*
the problem of failing to mount the filesystems
correctly, as other tests would fail with this error
if it were.
write and writev 16 (2 fails total), return failure
and ENOSPC when not expected. These tests are
attempting to check proper return when running out
of space, but are expecting to see a partial write
return instead of -1/ENOSPC, which should only
happen if no bytes can be written. Could potentially
be a kernel issue.
grantpt 1 (1 fail), this is running with a pseudo
filesystem mounted on /dev/pts, and the test detects
the unexpected presence of group-write permission on
the pty it tests. (620 instead of 600).
Reply to: