[Bug 623469] Unit test failures with CK_FORK=no make check

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=623469

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.9.1

--- Comment #8 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
commit 86c0058ae50ee633beaef4b177ede9529bdb9f16
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Mon Apr 11 10:44:22 2016 +0100

    tests: baseparse: make work with CK_FORK=no

    https://bugzilla.gnome.org/show_bug.cgi?id=623469

commit 1fa64722d0c69158872e744eaf9c8e38381bb574
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Mon Apr 11 10:27:56 2016 +0100

    tests: transform1: make test work with CK_FORK=no

    We need to clear some global state and register a new test
    basetransform subclass for each test because we do things
    in class_init base on global state.

    https://bugzilla.gnome.org/show_bug.cgi?id=623469

commit f9eb3b98f1858e2273696895827af2b9d86bfde1
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Sun Apr 10 20:45:24 2016 +0100

    tests: collectpads: fix for CK_FORK=no

    Reset global state when done, and unref sink pads too
    in teardown function to make it valgrind clean.

    https://bugzilla.gnome.org/show_bug.cgi?id=623469

commit 71f554009d549ebf9e6aec4d876714f92fe10c9e
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Sun Apr 10 20:25:44 2016 +0100

    tests: streamiddemux: fix with CK_FORK=no

    Clear global state when done.

    https://bugzilla.gnome.org/show_bug.cgi?id=623469

commit 4b9f2966fbf8e374725e67276d33cda752ce4439
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Sun Apr 10 20:04:07 2016 +0100

    tests: bufferpool: fix wrong assumptions about pointers and object
lifecycles

    The test assumed that if a buffer has the same pointer address as
    before it is in fact the same mini object and has been re-used by
    the pool. This seems to be mostly true, but not always. The buffer
    might be destroyed and when a new buffer is created the allocator
    might return the same memory that we just freed.

    Instead attach a qdata with destroy notify function to buffer
    instances we want to track to make sure the buffer actually
    gets finalized rather than resurrected and put back into the pool.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.