gsequencer fails autopkg tests on anything except amd64

[Matthias Klose]

gsequencer (1.4.34-1 to 2.1.34-1)
Maintainer: Debian Multimedia Maintainers
Section: universe/misc
15 days old
autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻

The Debian maintainer provided this analysis:
The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
it complained, that it can't allocate memory.

After assigning 8 GB of RAM the functional tests all passed on i386.

By the way I would love to mark the functional tests as flaky (see DEP-8)
https://dep-team.pages.debian.net/deps/dep8/

If we would package a more recent version of GSequencer we would be able
to run the unit-tests during autopkgtest.

Note, there 2 different types of tests unit-tests and functional
integration-tests. The
later are not mandatory to pass at my opinion. Especially if the VM
doesn't get enough
computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
if the delay is too long (not enough computing power) the tests aren't
reliable anymore.

To target this issue, I had to adjust the timeouts and delays. Yes,
the tests could run much
faster. But I decided to throttle them, to target environments will
lesser CPU resources than
I have on my workstation.

Here is the reaction time specified:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35

Here are the unit-tests to run against the installation:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-tests.mk.am?h=2.1.x

This is new for autopkgtest and not yet available:

https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/tests/ags-integration-unit-test

[Matthias Klose (doko)]

asked on #ubuntu-release:

<vorlon> gsequencer> why did it manage to run on amd64 without running out of memory?

[Steve Langasek (vorlon)]

> The qemu image has only 1 GB RAM assigned.

The Ubuntu autopkgtest runners each have 1.5GB of RAM. This includes amd64.

Why does gsequencer need more RAM to complete its tests on *i386* than it does on *amd64*?

We could bump the size of the runners used for this package, but I'm very skeptical of what this package's test suite would be doing that requires excessive amounts of RAM.

[Joël Krähemann (jkraehemann)]

Hi,
I could ask you, what lets you doubt that gdb wasn't able to allocate memory.
One more thing, media files tend to be large and require some RAM.

Might, be how memory is aligned as string? Internal memory representation?
CFLAGS or CPPFLAGS to glibc or even gcc.

The tests are using malloc() and what ever uses glib-2.0 and gobject-2.0.

bests,
Joël

On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
>
> Public bug reported:
>
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https://dep-team.pages.debian.net/deps/dep8/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35
>
> Here are the unit-tests to run against the installation:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https://salsa.debian.org/multimedia-
> team/gsequencer/blob/master/debian/tests/ags-integration-unit-test
>
> ** Affects: gsequencer (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> gsequencer in Ubuntu.
> Matching subscriptions: gsequencer, ubuntu-launchpad-gsequencer
> https://bugs.launchpad.net/bugs/1813456
>
> Title:
> gsequencer fails autopkg tests on anything except amd64
>
> Status in gsequencer package in Ubuntu:
> New
>
> Bug description:
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This...

[Joël Krähemann (jkraehemann)]

Hi again,
About excessive usage of RAM:
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/audio/osc/ags_functional_osc_server_test.c?h=2.1.x#n498

The test does enable network monitoring of ags-peak recall. The FFTW
created buffer is send for 16 channels across
the loopback device, 30 times per second with buffer-size of 256
during 20 seconds. Note the client and the server
uses 128 KB chunks.

This is basically some math:

16 * 20 * 30 * 131072 = 1258291200

Well, the test doesn't free any memory. During transmission 1.2GB are allocated.

Bests,
Joël

On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
>
> Public bug reported:
>
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https://dep-team.pages.debian.net/deps/dep8/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35
>
> Here are the unit-tests to run against the installation:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https://salsa.debian.org/multimedia-
> team/gsequencer/blob/master/debian/tests/ags-integration-unit-test
>
> ** Affects: gsequencer (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> gsequencer in Ubuntu.
> Matching subscriptions: gsequencer, ubuntu-launchpad-gsequencer
> https://bugs.launchpad.net/bugs/1813456
>
> Title:
> gsequencer fails autopkg tests on anything except amd64
>
> Status in gsequencer package in Ubuntu:
> New
>
> Bug description:
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64:...

[Joël Krähemann (jkraehemann)]

Hi,
As the amd64 VM might get -kvm switch or other performance accelerating options,
whereas other VMs just don't have.

The server might have a delay, and if its more than 4 seconds you have
approximately
additional 300 MB of RAM consumed.

This was just an idea.

Joël

On Sun, Jan 27, 2019 at 5:51 PM Joël Krähemann <email address hidden> wrote:
>
> Hi again,
> About excessive usage of RAM:
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/audio/osc/ags_functional_osc_server_test.c?h=2.1.x#n498
>
> The test does enable network monitoring of ags-peak recall. The FFTW
> created buffer is send for 16 channels across
> the loopback device, 30 times per second with buffer-size of 256
> during 20 seconds. Note the client and the server
> uses 128 KB chunks.
>
> This is basically some math:
>
> 16 * 20 * 30 * 131072 = 1258291200
>
> Well, the test doesn't free any memory. During transmission 1.2GB are allocated.
>
> Bests,
> Joël
>
> On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
> >
> > Public bug reported:
> >
> > gsequencer (1.4.34-1 to 2.1.34-1)
> > Maintainer: Debian Multimedia Maintainers
> > Section: universe/misc
> > 15 days old
> > autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
> >
> > The Debian maintainer provided this analysis:
> > The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> > reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> > it complained, that it can't allocate memory.
> >
> > After assigning 8 GB of RAM the functional tests all passed on i386.
> >
> > By the way I would love to mark the functional tests as flaky (see DEP-8)
> > https://dep-team.pages.debian.net/deps/dep8/
> >
> > If we would package a more recent version of GSequencer we would be able
> > to run the unit-tests during autopkgtest.
> >
> > Note, there 2 different types of tests unit-tests and functional
> > integration-tests. The
> > later are not mandatory to pass at my opinion. Especially if the VM
> > doesn't get enough
> > computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> > if the delay is too long (not enough computing power) the tests aren't
> > reliable anymore.
> >
> > To target this issue, I had to adjust the timeouts and delays. Yes,
> > the tests could run much
> > faster. But I decided to throttle them, to target environments will
> > lesser CPU resources than
> > I have on my workstation.
> >
> > Here is the reaction time specified:
> >
> > http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35
> >
> > Here are the unit-tests to run against the installation:
> >
> > http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-
> > tests.mk.am?h=2.1.x
> >
> > This is new for autopkgtest and not yet available:
> >
> > https://salsa.debian.org/multimedia-
> > team/gsequencer/blob/master/debian/tests/ags-integration-unit-test
> >
> > ** Affects: gsequencer (Ubuntu)
> > Importance: Undecided
> > Status: New
> >
> > --
> > You received this...

[Joël Krähemann (jkraehemann)]

Hi all,

Now, The functional tests have restrictions: flaky
https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/tests/control

bests,
Joël

On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
>
> Public bug reported:
>
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https://dep-team.pages.debian.net/deps/dep8/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35
>
> Here are the unit-tests to run against the installation:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https://salsa.debian.org/multimedia-
> team/gsequencer/blob/master/debian/tests/ags-integration-unit-test
>
> ** Affects: gsequencer (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> gsequencer in Ubuntu.
> Matching subscriptions: gsequencer, ubuntu-launchpad-gsequencer
> https://bugs.launchpad.net/bugs/1813456
>
> Title:
> gsequencer fails autopkg tests on anything except amd64
>
> Status in gsequencer package in Ubuntu:
> New
>
> Bug description:
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of R...

[Joël Krähemann (jkraehemann)]

Hi,

Just figured out the memory leak within the test is not that grave. But
rather the AgsOscMeterController not running dispose and unref on
AgsOscResponse object.

I think this should be definitely fixed.

Bests,
Joël

On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
>
> Public bug reported:
>
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https://dep-team.pages.debian.net/deps/dep8/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_test_util.c?h=2.1.x#n35
>
> Here are the unit-tests to run against the installation:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/unit-system-
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https://salsa.debian.org/multimedia-
> team/gsequencer/blob/master/debian/tests/ags-integration-unit-test
>
> ** Affects: gsequencer (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> gsequencer in Ubuntu.
> Matching subscriptions: gsequencer, ubuntu-launchpad-gsequencer
> https://bugs.launchpad.net/bugs/1813456
>
> Title:
> gsequencer fails autopkg tests on anything except amd64
>
> Status in gsequencer package in Ubuntu:
> New
>
> Bug description:
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/2.1.34-1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained,...