If I replace Glib::ustring by std::string, I don't have the memory leak. On Thu, Apr 1, 2010 at 13:22, Chris Vine <[email protected]>wrote:
> On Thu, 1 Apr 2010 11:03:32 +0200 > Fabian Jacquet <[email protected]> wrote: > > We use Glib::thread_init() because we had some crashes on multi > > thread with ustring. It was not a problem of variable protection, the > > crash happened when some threads used different ustring. Typically, > > if we parse different XML with libxml in different thread, we had > > crash on an ustring compare. The Glib::thread_init() resolved the > > crash. > > > > If you want a sample of the crash problem, I can send it to you. > > Maybe we don't have to use Glib::thread_init(). > > You will need to call Glib::thread_init() if you access glib from more > than one thread. As it happens Glib::ustring uses std::string > underneath, so that may cause trouble if your standard library uses > non-thread-safe lazy copy (copy on write), although it is difficult to > see how that is relevant to your particular example. > > What happens if you substitute std::string for Glib::ustring? If the > leak disappears then I find it very difficult to explain. glib uses > memory slices underneath, which will not immediately release memory in > case the memory will be reused, but I don't think invoking a > Glib::ustring constructor and comparison operator (as in your test > case) calls any glib functions requiring memory allocation and anyway > the leak looks larger than could be explained by this. > > If the leak does not disappear if you substitute std::string, since the > memory leak does appear to be thread related, do you need to use some > particular compiler flag to link in necessary windows thread support or > to make the standard library thread safe? (Sorry, I don't develop on > windows so this may be nonsense.) > > Chris >
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
