Re: ustring memory leak

[Fabian Jacquet <fabian jacquet gmail com>]

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 <chris cvine freeserve co uk> wrote:

On Thu, 1 Apr 2010 11:03:32 +0200
Fabian Jacquet <fabian jacquet gmail com> 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