I think you should file a bug. This simply should not happen.
I have no problem with the constructor.
I need to use a compare to have the memory leak.
I think your are right about memory slices. Do you think it's possible...
1) to free the slices when I finish my threads (my Windows threads)
I have no problem with the constructor.
I need to use a compare to have the memory leak.
I think your are right about memory slices. Do you think it's possible...
1) to free the slices when I finish my threads (my Windows threads)
or
2) to compile GLib without the feature which uses memory
Mh,
Very interesting, thank you.
I already try with G_SLICE=always-malloc environment variable and here is
the result.
Leak of 835584/1000 or 835
Leak of 811008/1000 or 811
Leak of 724992/1000 or 724
Leak of 720896/1000 or 720
Leak of 720896/1000 or 720
Leak of 724992/1000 or 724
Leak of
On Fri, 2 Apr 2010 14:13:28 +0200
Fabian Jacquet fabian.jacq...@gmail.com wrote:
I already try with G_SLICE=always-malloc environment variable and
here is the result.
Leak of 835584/1000 or 835
Leak of 811008/1000 or 811
Leak of 724992/1000 or 724
Leak of 720896/1000 or 720
Leak of
Ok, I will investigate in this way.
Thank you very much for your help.
I'm in holidays until Thursday. Maybe I will recontact you if I find
something.
Best regards.
On Fri, Apr 2, 2010 at 15:06, Chris Vine ch...@cvine.freeserve.co.ukwrote:
On Fri, 2 Apr 2010 14:13:28 +0200
Fabian Jacquet
2010/3/30 Chris Vine ch...@cvine.freeserve.co.uk:
You shouldn't need to change anything. Glib::RefPtr is only used by
gtkmm as far as I am aware in return values and as function arguments.
You should be able to use the auto keyword now with any gtkmm function
returning a RefPtr, with gcc-4.3
