On Thu, Apr 24, 2008 at 05:49:16PM +0200, Florian Weimer wrote: > Package: perl > Version: 5.8.8-7etch1 > Severity: serious > > To my knowledge, this bug only occurs on sparc in an etch chroot, > possibly only when running newer kernels. I cannot reproduce it with > the sid chroot on sperger. > The point at which the Perl process is terminated (IOW, number of lines > printed) varies from invocation to invocation. > > spontini, the sparc security build daemon, is similarly affected: > building perl sporadically fails as well, and it remains to be seen if > we can get it it to pass. Yeah, I can reproduce it on sperger/etch. It doesn't need the full Perl build tree, just running the system perl on ext/threads/t/stress_re.t (attached for convenience) shows the problem. It doesn't show up on my own sparc uniprocessor host, which has the Etch kernel, so it's either specific to new kernels or SMP hosts. As it works on sperger in the sid chroot, it would seem that newer versions of glibc work better. Looking at the glibc changelog, the threads implementation changed in 2.4.1 from LinuxThreads to NPTL, which sounds related. I don't really claim to know anything about their differences, though. CC'ing the debian-sparc list. help would be welcome. Bisecting with other kernel versions (sperger has 2.6.22.18sperger) might tell us something. Hm, one more data point: this was very easy to reproduce last night when sperger was empty, but now that there's some load from other people, the test completes almost all of the time. That would seem quite natural for a threading bug on an SMP host. Cheers, -- Niko Tyni ntyni@debian.org
Attachment:
stress_re.t
Description: Troff document