[Gtk-sharp-list] [Fwd: Re: Inexplicable segfaults]

Walter Leibbrandt walterl at indicium.za.net
Sat Sep 9 02:11:57 EDT 2006


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.



-------- Original Message --------
Subject: 	Re: [Gtk-sharp-list] Inexplicable segfaults
Date: 	Fri, 08 Sep 2006 08:30:08 +0700
From: 	Eric Albright <albright at wesayhome.org>
To: 	Walter Leibbrandt <walterl at indicium.za.net>

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 
I wonder if that would solve your problem as well.


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  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

More information about the Gtk-sharp-list mailing list