2012/10/5 Kris De Gussem <kris.degussem@...400...>:
Dear all
After recent bug reports ([1] and [2]) I had a look on the memory leak associated with the usage of share_string. share_string occupies some memory, but it apparently can afterwards never be released. Individual leaks are small, but there are many and the total memory leaked my quickly sum up. I have been studying the code, but I'm not able to figure out how ptr_shared works.
This class copies the object to garbage-collected memory. AFAIK it is used e.g. in the XML tree which is garbage-collected and does not use explicit memory management (though due to design failures one still has to call Inkscape::GC::release on every new XML node).
So I was wondering if someone could explain how ptr_shared works and if this explanation could be added to the source code in doxygen comments (and even the wiki?). Related to this question, why do we need a shared pointer system at all?
This is not a shared pointer system - the class is misleadingly named. I think it was supposed to become something similar to GQuark but the author stopped halfway. http://developer.gnome.org/glib/2.33/glib-Quarks.html
To solve the memory leak issue, I was thinking of replacing all calls to share_string with the usage of Glib::ustring (either directly or via ptr_shared). Is this a good idea or are there better options.
This will lead to memory leaks, because ptr_shared is used in garbage-collected structures, which AFAIK are removed from memory without calling destructors. Any memory used by normal std::strings in garbage-collected structures will be lost, unless the strings themselves use garbage-collected allocators. You should use std::basic_string<char, std::char_traits<char>, Inkscape::GC::Alloc>. The GC allocator is in src/gc-alloc.h, but it appears incomplete (the collection policy is not used at all). Note that it won't have the conveniences of Glib::ustring such as the index operator returning full Unicode characters or length() returning the number of characters rather than bytes, but it will store UTF-8 strings correctly.
Here is some info in case you want to modify the GC allocator: http://www.cplusplus.com/reference/std/memory/allocator/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Regards, Krzysztof