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.
Reply to: