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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
