and since that value is returned by Emf::open presumably something in the rest of Inkscape should be releasing it.
There is also a minor problem with the way extensions set up, which cause some memory to not be released before inkscape
exits. It isn't a leak so much because it only happens once, but it does muddy the waters when looking for real leaks. These are any calls like this:
which show up like this (so far always 4 bytes in 1 block):
==3499== 4 bytes in 1 blocks are still reachable in loss record 728 of 58,207
==3499== at 0x402B9B4: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3499== by 0x825C3AE: Inkscape::Extension::Internal::Emf::init() (emf-inout.cpp:3125)
==3499== by 0x638807F: ???
That is a lot more than 4 bytes, so it looks like something elsewhere is removing the contents but not deleting the pointer, or something like that.
Used "bzr update" to bring my local copy up to the changes ~suv noted in #15. Tested the updated lp988601 and it is still broken.
This is emf-inout.cpp:308
mod- >set_param_ string( "destination" , oldoutput);
and here is the associated valgrind record:
==3499== 22 bytes in 1 blocks are possibly lost in loss record 30,463 of 58,207 valgrind/ vgpreload_ memcheck- x86-linux. so) :Util:: share_string( char const*, unsigned int) (gc-core.h:77) :Util:: share_string( char const*) (share.cpp:20) :XML::SimpleNod e::setAttribute (char const*, char const*, bool) (simple- node.cpp: 375) :Preferences: :_setRawValue( Glib::ustring const&, char const*) (preferences. cpp:732) :Extension: :ParamString: :set(char const*, SPDocument*, Inkscape: :XML::Node* ) (string.cpp:64) :Extension: :Internal: :Emf::save( Inkscape: :Extension: :Output* , SPDocument*, char const*) (emf-inout.cpp:308) :Extension: :Output: :save(SPDocumen t*, char const*) (output.cpp:218) :Extension: :save(Inkscape: :Extension: :Extension* , SPDocument*, char const*, bool, bool, bool, Inkscape: :Extension: :FileSaveMethod ) (system.cpp:343) saveRN3Gtk6Wind owEP10SPDocumen tRKN4Glib7ustri ngEPN8Inkscape9 Extension9Exten sionEbbNS9_ 14FileSaveMetho dE.constprop. 345 (file.cpp:625) save_dialog( Gtk::Window& , SPDocument*, Inkscape: :Extension: :FileSaveMethod ) (file.cpp:897)
==3499== at 0x402BE68: malloc (in /usr/lib/
==3499== by 0x8519BBE: Inkscape:
==3499== by 0x8519CAE: Inkscape:
==3499== by 0x834A4AD: Inkscape:
==3499== by 0x80DEAC2: Inkscape:
==3499== by 0x8200199: Inkscape:
==3499== by 0x825B1DC: Inkscape:
==3499== by 0x8203CF6: Inkscape:
==3499== by 0x82026BF: Inkscape:
==3499== by 0x80B0049: _ZL9file_
==3499== by 0x80AFA7E: sp_file_
==3499== by 0xA7D25A3: ???
The other set_param_string lines all generate memory leaks too. So do set_param_bool lines like emf-inout.cpp:338
ext- >set_param_ bool("FixPPTCha rPos",new_ FixPPTCharPos) ;
==3499== 2 bytes in 1 blocks are definitely lost in loss record 474 of 58,207 valgrind/ vgpreload_ memcheck- x86-linux. so) :Util:: share_string( char const*, unsigned int) (gc-core.h:77) :Util:: share_string( char const*) (share.cpp:20) :XML::SimpleNod e::setAttribute (char const*, char const*, bool) (simple- node.cpp: 375) :Preferences: :_setRawValue( Glib::ustring const&, char const*) (preferences. cpp:732) :Extension: :ParamBool: :set(bool, SPDocument*, Inkscape: :XML::Node* ) (bool.cpp:61) :Extension: :Internal: :Emf::save( Inkscape: :Extension: :Output* , SPDocument*, char const*) (emf-inout.cpp:338) :Extension: :Output: :save(SPDocumen t*, char const*) (output.cpp:218) :Extension: :save(Inkscape: :Extension: :Extension* , SPDocument*, char const*, bool, bool, bool, Inkscape: :Extension: :FileSaveMethod ) (system.cpp:343) saveRN3Gtk6Wind owEP10SPDocumen tRKN4Glib7ustri ngEPN8Inkscape9 Extension9Exten sionEbbNS9_ 14FileSaveMetho dE.constprop. 345 (file.cpp:625) save_dialog( Gtk::Window& , SPDocument*, Inkscape: :Extension: :FileSaveMethod ) (file.cpp:897)
==3499== at 0x402BE68: malloc (in /usr/lib/
==3499== by 0x8519BBE: Inkscape:
==3499== by 0x8519CAE: Inkscape:
==3499== by 0x834A4AD: Inkscape:
==3499== by 0x80DEAC2: Inkscape:
==3499== by 0x81FA69E: Inkscape:
==3499== by 0x825B00A: Inkscape:
==3499== by 0x8203CF6: Inkscape:
==3499== by 0x82026BF: Inkscape:
==3499== by 0x80B0049: _ZL9file_
==3499== by 0x80AFA7E: sp_file_
==3499== by 0xD44B7B3: ???
This may or may not be related - there is also what looks like a double delete() event associated with emf-inout.cpp:303
mod- >base-> invoke_ hide(mod- >dkey);
which does this:
==3499== Mismatched free() / delete / delete [] valgrind/ vgpreload_ memcheck- x86-linux. so) :DrawingShape: :~DrawingShape( ) (drawing- shape.cpp: 42) :DrawingShape: :~DrawingShape( ) (drawing- shape.cpp: 48) :invoke_ hide(unsigned int) (sp-item.cpp:1121) :hide(unsigned int) (sp-item- group.cpp: 783) :invoke_ hide(unsigned int) (sp-item.cpp:1100) :hide(unsigned int) (sp-item- group.cpp: 783) :invoke_ hide(unsigned int) (sp-item.cpp:1100) :hide(unsigned int) (sp-item- group.cpp: 783) :invoke_ hide(unsigned int) (sp-item.cpp:1100) :Extension: :Internal: :Emf::save( Inkscape: :Extension: :Output* , SPDocument*, char const*) (emf-inout.cpp:303) valgrind/ vgpreload_ memcheck- x86-linux. so) :set(SPStyle* ) (nr-style.cpp:134) :sp_shape_ show(SPItem* , Inkscape::Drawing&, unsigned int, unsigned int) (sp-shape.cpp:801) :invoke_ show(Inkscape: :Drawing& , unsigned int, unsigned int) (sp-item.cpp:1047) :_showChildren( Inkscape: :Drawing& , Inkscape: :DrawingItem* , unsigned int, unsigned int) (sp-item- group.cpp: 768) :show(Inkscape: :Drawing& , unsigned int, unsigned int) (sp-item- group.cpp: 756)
==3499== at 0x402ACFC: operator delete(void*) (in /usr/lib/
==3499== by 0x81E8C64: NRStyle::~NRStyle() (nr-style.cpp:63)
==3499== by 0x81CE8DF: Inkscape:
==3499== by 0x81CE92F: Inkscape:
==3499== by 0x812A51D: SPItem:
==3499== by 0x812F256: CGroup:
==3499== by 0x812A470: SPItem:
==3499== by 0x812F256: CGroup:
==3499== by 0x812A470: SPItem:
==3499== by 0x812F256: CGroup:
==3499== by 0x812A470: SPItem:
==3499== by 0x825B1AA: Inkscape:
==3499== Address 0xc1bd3e0 is 0 bytes inside a block of size 16 alloc'd
==3499== at 0x402B454: operator new[](unsigned int) (in /usr/lib/
==3499== by 0x81E921B: NRStyle:
==3499== by 0x816B10C: SPShape:
==3499== by 0x812BEDC: SPItem:
==3499== by 0x812F34E: CGroup:
==3499== by 0x813156C: CGroup:
And also, as long as we are at it, this leaks (emf-inout. cpp:3083) :
SPDocument *doc = SPDocument: :createNewDocFr omMem(d. outsvg- >c_str( ), strlen( d.outsvg- >c_str( )), TRUE);
and since that value is returned by Emf::open presumably something in the rest of Inkscape should be releasing it.
There is also a minor problem with the way extensions set up, which cause some memory to not be released before inkscape
exits. It isn't a leak so much because it only happens once, but it does muddy the waters when looking for real leaks. These are any calls like this:
Inkscape: :Extension: :build_ from_mem(
"<inkscape- extension xmlns=\"" INKSCAPE_ EXTENSION_ URI "\">\n"
"< name>" N_("EMF Input") "</name>\n"
"< id>org. inkscape. input.emf< /id>\n"
"< input>\ n"
"<extension> .emf</extension >\n"
"<mimetype> image/x- emf</mimetype> \n"
"<filetypenam e>" N_("Enhanced Metafiles (*.emf)") "</filetypename>\n"
"<filetypetoo ltip>" N_("Enhanced Metafiles") "</filetypetool tip>\n"
"<output_ extension> org.inkscape. output. emf</output_ extension> \n"
"< /input> \n"
"</inkscape- extension> ", new Emf());
which show up like this (so far always 4 bytes in 1 block):
==3499== 4 bytes in 1 blocks are still reachable in loss record 728 of 58,207 valgrind/ vgpreload_ memcheck- x86-linux. so) :Extension: :Internal: :Emf::init( ) (emf-inout. cpp:3125)
==3499== at 0x402B9B4: operator new(unsigned int) (in /usr/lib/
==3499== by 0x825C3AE: Inkscape:
==3499== by 0x638807F: ???
That is a lot more than 4 bytes, so it looks like something elsewhere is removing the contents but not deleting the pointer, or something like that.