I decided to construct a new GtkBuilder every time, and destroy it. It
works for me. My xml files are not that big anyway.
On Tue, 2012-12-04 at 01:33 +0900, Tristan Van Berkom wrote:
Probably you want to use GResource to store your builder
xml (or const gchar* memory) instead of scratching
On Thu, Dec 6, 2012 at 3:25 PM, David Nečas y...@physics.muni.cz wrote:
So, they are all trying to lock allocator-slab_mutex in GSlice.
But nothing seems to hold it.
Could that be messed up by forking somehow?
Could you please advise how to debug it further, to rule out the
possibility of
On Fri, Dec 07, 2012 at 05:53:57AM -0500, Matthias Clasen wrote:
See https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork is just a bad idea, doubly so with threads (and every
glib program is using threads nowadays)a
Thanks, somehow, I missed that bug.
Regards,
Yeti
On Thu, 6 Dec 2012 21:25:47 +0100
David Nečas y...@physics.muni.cz wrote:
can g_slice_alloc() be made to deadlock simply by some bad sequence of
GLib function calls, considering the calling program does not, of
course, hold any GLib lock explicitly? (Without a GLib bug, that is.)
I am
On Fri, Dec 07, 2012 at 08:44:01PM +, Chris Vine wrote:
...
So for your scheme to work, the parent before forking must be single
threaded.
As I have learnt the hard way, this is not something I can ensure even
the program does not use any multi-threading itself because libraries
may. Even
On Fri, 7 Dec 2012 22:37:27 +0100
David Nečas y...@physics.muni.cz wrote:
On Fri, Dec 07, 2012 at 08:44:01PM +, Chris Vine wrote:
...
So for your scheme to work, the parent before forking must be single
threaded.
As I have learnt the hard way, this is not something I can ensure even
