Hi, Eric is 100% correct: it is a related problem and the Gdk.Threads.Enter()/Leave() methods around all Gtk-related method calls did the trick.
I would just like to know what the (expected) performance implication would be in using this. Thanks, Walter -------- Original Message -------- Subject: Re: [Gtk-sharp-list] Inexplicable segfaults Date: Fri, 08 Sep 2006 08:30:08 +0700 From: Eric Albright <[EMAIL PROTECTED]> To: Walter Leibbrandt <[EMAIL PROTECTED]> This sounds very much like the problem we had encountered (we were also dynamically creating/destroying widgets). I mentioned our solution already on the list http://lists.ximian.com/pipermail/gtk-sharp-list/2006-September/007388.html. I wonder if that would solve your problem as well. Eric www.wesay.org Walter Leibbrandt wrote: > Hi, > > I'm currently busy with a program that mixes Glade and custom managed > Gtk widgets. All the Glade files are loaded with a Gtk.Fixed as the root > and Put() on a custom-created Gtk.Window and shown/hidden according to > button press events. The weird thing is that I get a segfault every few > "layout changes" (no particular/reproducible sequence of changes): > > <output> > ================================================================= > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > ================================================================= > > Stacktrace: > > at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00004> > at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff> > at Gtk.Application.Run () <0x00007> > at MainClass.Main (string[]) [0x0003a] in /path/to/program/src/Main.cs:39 > at (wrapper runtime-invoke) > System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) > <0xffffffff> > > Native stacktrace: > > mono(mono_handle_native_sigsegv+0xf4) [0x815f9f4] > mono [0x8149bb3] > [0xffffe440] > </output> > > This program is not multi threaded, although all used events are > connected to custom classes which manages the events through my own > event queue and handler(s). Here's my Main() method (ignore the > Initializer and UIMan lines; it sets up/loads the UI, etc...): > > <code> > public static void Main(string[] args) > { > Gtk.Application.Init(); > > Initializer.Initialize(); > > IUIManager UIMan = (IUIManager) > ObjectManager.Instance[typeof(IUIManager)]; > > UIMan.Test(); > > Gtk.Application.Run(); //Line 39 > Gtk.Application.Quit(); > } > </code> > > I would assume that something like this would be a possible (or more > likely) race condition if I were to enqueue these layout change events > faster than it can be handled, but I made sure that I wait for all > events to be processed before changing to another layout. > > Any ideas on how to fix this? > > Thanks in advance, > > Walter Leibbrandt > > P.S. Unfortunately I'm not in the position to share all the code because > of a stupid NDA. :( > _______________________________________________ > Gtk-sharp-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list > > _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
