GNOME Bugzilla – Bug 451276
[gstcheck] fail_if() etc. are not thread safe
Last modified: 2010-02-24 11:03: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.
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).
> (...) 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
This was fixed by commit 53209f02 between 0.10.25 and 0.10.26.