After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 451276 - [gstcheck] fail_if() etc. are not thread safe
[gstcheck] fail_if() etc. are not thread safe
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.26
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-26 15:09 UTC by Jan Schmidt
Modified: 2010-02-24 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Schmidt 2007-06-26 15:09:25 UTC
Each fail_if and fail_unless call to libcheck sends the current execution position to the parent process, so it can write some information about where the child crashed in case it does.... but there's no locking in libcheck and we call the macros from lots of different threads in our tests.

I think this may be the cause of an intermittent "Bad message type arg" error I'm getting in the core tests/check/elements/multiqueue test.
Comment 1 Olivier Crête 2009-04-16 19:51:39 UTC
In farsight2, I have a macros that wraps them in a mutex.
I guess gstcheck could provide these macros, or maybe we could just switch over to GTest when our GLib version requirement reaches 2.16 (or we could just require 2.16 to run the tests).
Comment 2 Tim-Philipp Müller 2009-04-16 20:40:09 UTC
> (...) or maybe we could just switch over
> to GTest when our GLib version requirement reaches 2.16 (or we could just
> require 2.16 to run the tests).

IIRC multiple people who have looked at GTest voiced an opinion along the lines of "GTest just isn't good enough, let's stick to check", but I don't remember any details or whether it'd be much work to fix it up.

Link to farsight macros:
http://git.collabora.co.uk/?p=farsight2.git;a=blob;f=tests/check/check-threadsafe.h;h=e40cb4cb93c28dabf0aa543f7bc05899ad72f643;hb=HEAD
Comment 3 Tim-Philipp Müller 2010-02-24 11:03:25 UTC
This was fixed by commit 53209f02 between 0.10.25 and 0.10.26.