[pulseaudio-discuss] Pulseaudio test suite failures

[Felipe Sateler]

On Fri, Aug 1, 2014 at 2:14 AM, Peter Meerwald <pmeerw at pmeerw.net> wrote:
>
> Hello,

Hi,

>
> > In the latest version of pulseaudio in Debian I enabled the test suite
> > at build time. Unfortunately, this resulted in failures in almost all
>
> thanks for reporting!
>
> > builds[1]. Several test failures occurred due to timeouts, which I
> > think could be fixed by simply extending the timeout period. These are
> > either in the thread or volume tests. However, many tests failed due
> > to assertions:
>
> I'm trying to reproduce (which is tedious); it would be easier if one
> could investigate the build machines...

The build machines themselves are restricted. But I have access to
machines that are hopefully similar enough, provided by Debian. So I
can try any patches you offer for build, but unfortunately not for
actual audio playing.

There is a process to get access to the porter boxes to third-parties,
so if you are interested we could arrange that, but it will probably
take some time to set up.

>
> > On freebsd, we couldn't build:
> >
> > Debian does not #define __FreeBSD__ but instead defines
> > __FreeBSD_kernel__. This seems to have changed recently. I don't know
> > if real FreeBSD defines the kernel variant, but
>
> > On hurd-i386:
> >
> > tests/get-binary-name-test.c:44:F:getbinaryname:getbinaryname_test:0: Failed
>
> gah, I'm not going to install hurd :)

:)

> this tests one function, pa_get_binary_name() in src/pulse/util.c, if
> /proc/self/exe exists, an #ifdef could be added for hard

Hmm, this indeed appears to be missing functionality in hurd:

https://lists.gnu.org/archive/html/help-hurd/2011-10/msg00003.html

>
> I think pa_mix_s24_32re_c() is simply wrong, and has never worked; it
> should advance m->ptr by sizeof(int32_t), not 3 -- will submit a fix and
> update the test code

I can test the patch, if you can send me one :)

>
> > On armel:
> >
> > tests/mix-test.c:266:F:mix:mix_test:0: Assertion '*u == *v' failed
> >
> > On Powerpc:
> >
> > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed
> >
> > On s390x:
> >
> > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed
> >
> > On mips:
> >
> > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed
> >
> > On sparc:
> >
> > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed
>
> > I may need to disable it anyway because on some archs the thread-test
> > seems to take just too long (or perhaps there is a race?). But I
> > thought I should report here the results anyway.
>
> is this emulated or real hardware; some tests take long, so we could just
> increase the allowed time

I can't remember which architecture appeared to hang, but I can try
again tomorrow hopefully. But they where all real hardware, except for
the kfreebsd boxes.

I was thinking of just disabling the timeouts by setting
CK_TIMEOUT_MULTIPLIER  to 0.

The debian build daemons do have a timeout killer as well.

-- 

Saludos,
Felipe Sateler