Re: LSB 3.1 status for etch
On Fri, 2006-10-06 at 23:16 +0200, Andreas Barth wrote:
> Jeff, please continue with your tests.
Unfortunately, I must report some bad news: etch has regressed.
I've tested powerpc and i386. I apologize for the delay, but initially
I had thought the regression was specific to powerpc, as I had not run
tests on that platform until recently. Seeing identical failures on
i386 has confirmed that the regression is most likely cross-platform.
The other architectures I have available to me are ia64 and amd64, but I
don't see much point in testing them until I have a handle on these
issues. The powerpc tests had another problem, but my guess is that
this is a test suite deficiency and not a problem with Debian.
The two tests are:
/tset/LSB.os/mfiles/msync_P/T.msync_P 7 FAIL
/tset/LSB.os/procenv/nice/T.nice 9 FAIL
Here are the respective journal entries:
10|852 /tset/LSB.os/mfiles/msync_P/T.msync_P 22:58:49|TC Start, scenario ref 858-0
15|852 3.6-lite 9|TCM Start
400|852 7 1 22:59:13|IC Start
200|852 7 22:59:13|TP Start
520|852 7 00008662 1 1|msync() did not return -1, returned 0
220|852 7 1 22:59:13|FAIL
410|852 7 1 22:59:13|IC End
80|852 0 22:59:15|TC End, scenario ref 858-0
10|866 /tset/LSB.os/procenv/nice/T.nice 22:59:40|TC Start, scenario ref 872-0
15|866 3.6-lite 9|TCM Start
400|866 9 1 22:59:40|IC Start
200|866 9 22:59:40|TP Start
520|866 9 00008759 1 1|nice(-1) did not return expected values
520|866 9 00008759 1 2|ERRNO VALUES: expected: 1 (EPERM), observed: 0 (NO ERROR)220|866 9 1 22:59:40|FAIL
410|866 9 1 22:59:40|IC End
80|866 0 22:59:41|TC End, scenario ref 872-0
The msync() issue has to do with attempting to sync a section of memory
that had been munmap()ed. This should return an error, but does not.
The nice() issue is a fairly straightforward attempt by the test process
to increase its own priority by calling nice(-1), which appears to be
succeeding. This has the potential to be a security issue.
I am continuing to investigate both of these, and will report any
findings. I don't think I have enough data to file bugs just yet; in
particular, my efforts to write standalone test code to duplicate the
msync() bug have not yet succeeded.
I can report, however, that the msync() failure does go away when the
test is run under kernels 2.6.15-1-686 and 2.6.16-2-686 (on the i386
architecture), but appears with kernels 2.6.17-2-686 and 2.6.18-1-686.
The nice() failure happens on all four. Since my previous etch tests
had been run under 2.6.15-1-686, and did not exhibit either problem,
this implies that the msync() bug may be in the kernel, while the nice()
bug may be in libc. This is entirely preliminary, however.