Bug#625828: libipc-sharelite-perl: FTBFS on armel: test failures

[Niko Tyni]

On Sun, May 08, 2011 at 09:43:55AM +0300, Niko Tyni wrote:
> On Fri, May 06, 2011 at 12:38:42PM +0300, Niko Tyni wrote:
> > Package: libipc-sharelite-perl
> > Version: 0.17-1
> > Severity: serious
> > Tags: wheezy sid
> > User: debian-perl at lists.debian.org
> > Usertags: perl-5.12-transition
> > 
> > This package failed to build on armel only against Perl 5.12.
> > 
> >  https://buildd.debian.org/status/fetch.php?pkg=libipc-sharelite-perl&arch=armel&ver=0.17-1%2Bb1&stamp=1304522076

> I can reproduce this on abel.debian.org with both squeeze (Perl 5.10)
> and sid (5.12), but not on agricola.debian.org at all. Either kernel or
> hardware specific? I see from the build log that arnold.debian.org (the
> buildd) is running "Linux 2.6.32 armel (armv5tel)" which matches abel.

It also failed on ancina.d.o ("Linux 2.6.31-rc9 armel (armv5tel)")
and alwyn.d.o ("Linux 2.6.32 armel (armv5tel)"). Dominic uploaded a
binary package built on agricola.d.o (2.6.26-2-iop32x), where it
never fails.

The code uses semaphore operations for locking shared memory, and the
bug seems to be that attaching the same shared memory segment twice and
then accessing the second copy breaks locking altogether.

I have narrowed the problem down to the attached pure C test case,
which fails almost all the time for me on abel.d.o but never anywhere
else I've tried.

I'm not intimately familiar with SysV IPC, but my reading of the semop(2)
and related manual pages indicates the code should work. I think this
looks like a kernel regression on armel, but I'm certainly happy to be
proved wrong.

@debian-arm: could some porters please test this (running it a dozen
times or so to see how consistent the result is) and report back with
the results and kernel versions? Please compile it without optimization,
otherwise the memory access triggering the bug gets optimized away.

abel% while   ! ./a.out 5000; do :; done
not ok 1 - got 5000, expected 10000
not ok 1 - got 8242, expected 10000
not ok 1 - got 9342, expected 10000
not ok 1 - got 5000, expected 10000
not ok 1 - got 7159, expected 10000
not ok 1 - got 5000, expected 10000
not ok 1 - got 9223, expected 10000
ok 1 - got 10000, expected 10000

Thanks,
-- 
Niko Tyni   ntyni at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 3679 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20110514/a16d913c/attachment.c>