Bug 18025 - [GtkSharp 2.12 release codeline] broken semaphore usage in Object.cs
Summary: [GtkSharp 2.12 release codeline] broken semaphore usage in Object.cs
Status: NEW
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: 2.x
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL: https://github.com/mono/gtk-sharp/pul...
Depends on:
Reported: 2014-02-26 11:44 UTC by Steffen
Modified: 2014-09-12 16:03 UTC (History)
4 users (show)

Tags: threadsafeness multithreading semaphore dictionary threads thread
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 18025 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Steffen 2014-02-26 11:44:01 UTC
In the GtkSharp 2.12 codeline, file Object.cs contains a trivial but severe error in its semaphore usage.

The variable "Objects" is protected by lock() {...} statements, but:
not in all locations.

Just SOME use that protection.

This leads to the effect that the access to that dictionary in fact is NOT threadsafe at all.

The fix is very easy: just add the missing lock() { ... } protections in the missing places.

I have already implemented the correction, and filed a pull request on github for it.

May I _please_ ask for a 2.12 update containing that fix?

The mentioned pull request contains a second, additive change:
it backports the *.sln buildprocess from the "master" codeline to the "2.12" release codeline.
Thus, in that codeline then a buildprocess via
Visual Studio resp. MonoDevelop resp. Xamarin Studio is possible again,
which was a great help for us finding the above threadsafeness bug.

Please also check to port this bugfix into the master codeline.
Comment 1 Steffen 2014-02-26 11:49:53 UTC
This threadsafeness issue is very subtle.

We are aware of that GtkSharp in itself is thread-aware but not thread-safe
on its own.

We are taking care in our calling code of that by using proper

   // do some GtkSharp GUI elements operation here

sections. However, the broken dictionary Object.cs hits us directly
during the startup phase of our application. The missing threadsafeness
results in a broken "Objects" dictionary, i.e., with elements missing in it.

Thus, this broken dictionary results in a missing connection between
C++ Gtk objects and their C# counterparts.

As a consequence, GtkSharp tries to re-construct the missing ones
by invoking their "IntPtr constructor", which for many of our own GUI classes
simply does not exist. This leads to exceptions of the type
"missing IntPtr constructor in class XYZ".

However, the real cause of the trouble is not that missing constructor,
but the broken "Objects" dictionary which relates the C++ objects with its
C# counterparts.

This bug hits us quite badly, and we would be grateful for an official
2.12 bugfix update.
Comment 2 Steffen 2014-02-26 14:31:59 UTC
proposed bug fix

Comment 3 Steffen 2014-03-11 07:01:03 UTC
ping, can this (simple but important) fix please be taken over?

it is just a handful of adding missing semaphore usages.

a patch already is available for takeover at

Comment 4 Bertrand Lorentz 2014-06-05 06:05:53 UTC
For the record, the pull request mentioned above has been merged in the gtk-sharp-2-12-branch.

So this bug can be closed (I don't have the access rights to do it myself).
Comment 5 Steffen 2014-06-05 06:29:33 UTC
hmmm, I am not sure if that is a good idea:

YES, the fix is now contained in the GtkSharp 2.12 codeline now, but

as far as I know, Xamarin has not yet released a 
GtkSharp 2.12 update containing it.

Before that has happened, this issue shouldn't be closed IMHO.

The issue is about the crashes users experience with the official
Xamarin GtkSharp delivery.

Is any release manager from Xamarin reading this maybe?
Could you publish that GtkSharp update, please?
Comment 6 Antonius Riha 2014-09-12 16:03:19 UTC
Xamarin has released gtk-sharp 2.12.26: http://download.xamarin.com/GTKforWindows/Windows/gtk-sharp-2.12.26.msi containing your fixes: https://github.com/mono/gtk-sharp/releases/tag/gtk-sharp-2.12.26