GNOME Bugzilla – Bug 662071
Crash in Clutter-master (due to changes brought about by GLib Threading API overhaul)
Last modified: 2011-10-24 17:13:10 UTC
Hi, As I was attempting to compile Clutter on Windows, I came across exception 0xC0000264: 應用程式嘗試釋放不是自已的資源 (The application attempted to release resources that it did not own), which caused programs in tests/micro-bench to crash, and it does seem to me that this could have well been brought about by the changes that were done due to the recent massive changes in GLib's threading API. All these programs crashed when "void clutter_threads_leave()" was being called- and interestingly this only happened on Win32, but the programs ran fine on Linux. Thank you, and God bless!
Hi, (Sorry, I hope I do not sound bad or offensive here) After further investigation, by reverting the changes brought by commit 7e3a75c66bbca1e278b15c797cfc6acbcbd6c7c7 (Deprecate clutter_threads_init())[1], the problem was resolved as a result-but I am not sure whether this will be alright in the big picture-but it seems to me that the changes in clutter-main.c and clutter-main.h in that commit brought about these problems. Thank you, and God bless! [1]: http://git.gnome.org/browse/clutter/commit/?h=msvc-support-master&id=5419c11c99f721f2f9bf520c0444c053a88b3725 http://git.gnome.org/browse/clutter/commit/?h=msvc-support-master&id=3d74552684a6eb49bc67845bfb3839896395e66a
clutter_threads_init() just allocated the GMutex and set the lock/unlock function pointers; the GMutex is now in static storage (and it's initialized through g_mutex_init() for good measure), and the function assignment is now done in clutter_base_init() - so I'm a bit puzzled as to why that would be a problem.
Created attachment 199799 [details] [review] Patch to not initiliaze the Big Clutter Lock on Windows Hi Emmanuele, After further investigation, I think the problem occurred as we entered clutter_threads_init_default after entering the "GUI" part of Clutter, which called the GUI system of Windows. The problem with this is, as in the case of GTK+[1], is that the GUI system of Windows is by itself multithreaded[2] while X11 is not, so doing/initing the locking/unlocking in the GUI portion would cause problems as a result. Probably the best solution for this is to initialize the Big Clutter Lock before we enter the GUI portion of Clutter, or not to initialize the Big Clutter Lock on Win32 at all, as GObject automatically initializes threading support. The patch I put here is for not initializing the Big Clutter Lock on Windows. Thanks, and God bless!
Sorry, missed some details from the last post: [1]: Multi-threaded use of GTK+ on Win32 in README.win32 of GTK+ source package [2]: Explanation of Windows GUI system regarding its multithreadness assumtopns-http://lists-archives.org/gtk/12724-compiling-a-gtk-application-on-windows.html Thanks, and God bless!
Review of attachment 199799 [details] [review]: I agree on the patch in principle, though you should probably leave a comment as to why we need to skip the initialization on Windows, so that I don't forget later on. :-) ::: clutter/clutter-main.c @@ +216,3 @@ g_mutex_init (&clutter_threads_mutex); +#ifndef HAVE_CLUTTER_WIN32 this should be: #ifndef CLUTTER_WINDOWING_WIN32 which is the macro we use for the windowing system.
the comment would be a simple: /* we don't need locking functions on Windows. * see bug: https://bugzilla.gnome.org/show_bug.cgi?id=662071 */ the bug link and the blame log will do the rest.
Created attachment 199842 [details] [review] Don't init the Big Clutter Lock on Windows Hi Emmanuele, Agreed-the patch is updated here. Thanks, and God bless!
Review of attachment 199842 [details] [review]: looks good to me.
Review of attachment 199842 [details] [review]: Committed as 8c196c94-will close this bug shortly. Thanks, and God bless!