Hi, I'm testing out the .42 version for translation consistency but I can't get it to compile the extensions. I have read Aaron's doc on dependency: http://www.ekips.org/comp/inkscape/depends.php I have the packages mentioned there but still the ./configure script says at the end:
Use Xft font database: yes Use gnome-print: no Use gnome-vfs no Use openoffice files: yes Use MMX optimizations: yes Use relocation support: no Use Python extensions: skipped Use Perl extensions: skipped
I still don't have the "Effects" menu Am I missing some step here?
Thanks,
Lucas Vieites wrote:
I have the packages mentioned there but still the ./configure script says at the end:
Use Python extensions: skipped Use Perl extensions: skipped
Don't worry. This is refering to embedded interpreters. I don't think they are full usable yet. The effects that I am aware of only use the external scripting support and so the embedded interpreters are not necessary.
I still don't have the "Effects" menu Am I missing some step here?
You will still need to do just a little bit of editing in preferences.xml. Check out step six on this wiki page: http://www.inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking/Windows
Just a guess but there are probably only 3 translatable strings in the effects menu.
Aaron Spike
On Thu, Jun 09, 2005 at 08:10:56PM +0200, Lucas Vieites wrote:
Hi, I'm testing out the .42 version for translation consistency but I can't get it to compile the extensions. I have read Aaron's doc on dependency: http://www.ekips.org/comp/inkscape/depends.php I have the packages mentioned there but still the ./configure script says at the end:
Use Xft font database: yes Use gnome-print: no Use gnome-vfs no Use openoffice files: yes Use MMX optimizations: yes Use relocation support: no Use Python extensions: skipped Use Perl extensions: skippedI still don't have the "Effects" menu Am I missing some step here?
You also need to turn on the menu in your preferences.xml file. ;-)
Bryce
Bryce Harrington wrote:
On Thu, Jun 09, 2005 at 08:10:56PM +0200, Lucas Vieites wrote:
I still don't have the "Effects" menu Am I missing some step here?
You also need to turn on the menu in your preferences.xml file. ;-)
In CVS this can be done from the Misc tab in the Inkscape Preferences dialog.
Aaron Spike
Hi alltogether,
On Mon, Jun 20, 2005 at 06:43:13AM -0500, aaron@...749... wrote:
Bryce Harrington wrote:
On Thu, Jun 09, 2005 at 08:10:56PM +0200, Lucas Vieites wrote:
I still don't have the "Effects" menu Am I missing some step here?
You also need to turn on the menu in your preferences.xml file. ;-)
In CVS this can be done from the Misc tab in the Inkscape Preferences dialog.
I have the problem with the effects menu too. (debian unstable, cvs last week). I deleted .inkscape in my homedir and had a look in the dialog you mention but I don't see any possibility to enable the menu there (see attached screenshot). I also have problems with 3 extensions, but I don't know yet if I should configure --with-python --with-perl to get them working. I update from cvs atm an will recompile soon. The affacted extensions are:
Extension "Blur Edge" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: bluredge
Extension "GIMP Gradients" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: gimpgrad
Extension "Grid" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: grid
Thanks,
Wolfi
Aaron Spike
Wolfram Quester wrote:
On Mon, Jun 20, 2005 at 06:43:13AM -0500, aaron@...749... wrote:
Bryce Harrington wrote: In CVS this can be done from the Misc tab in the Inkscape Preferences dialog.
I have the problem with the effects menu too. (debian unstable, cvs last week). I deleted .inkscape in my homedir and had a look in the dialog you mention but I don't see any possibility to enable the menu there (see attached screenshot). I also have problems with 3 extensions, but I don't know yet if I should configure --with-python --with-perl to get them working. I update from cvs atm an will recompile soon. The affacted extensions are:
Extension "Blur Edge" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: bluredge
Extension "GIMP Gradients" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: gimpgrad
Extension "Grid" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: grid
Yeah, the effects menu checkbox in the preferences dialog is pretty new. I think it was added Friday or Saturday.
You do not need to configure with python or perl. But I don't know what you need to do to get those plugins working. I think I remember Ted saying he was going to disable plugins for a while while he rearchitectured things. I was hoping that he would fill us in when he gets back.
If you do get it to work please record your steps on the wiki: http://inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking
Aaron Spike
On Mon, Jun 20, 2005 at 08:26:39AM -0500, aaron@...749... wrote: [...snip...]
Yeah, the effects menu checkbox in the preferences dialog is pretty new. I think it was added Friday or Saturday.
Ah, thenks I rebuilt inkscape from up-to-date cvs and enabled then menu via the preferences dialog and playing around with the effects gives great fun. I thought that cvs had it enabled by default, but it was not. But we should rename the first two entries: Previous Effect Previous Effect... Only the message in the status bar tells me the difference.
Kochify gives me an error on the console: No preferences for Effect
The Fret Find things give me Scala scale description file expected. Extension::Script: Unknown error for pclose : Success This should be more user friendly and perhaps an example description file could be provided.
Using dropshadow on a Lindenmayer curve gives me sometimes just a copy of the curve, sometimes a great shadow.
While experimenting I had one crash. I repeatedly used some effects and inkscape crashed, but without closing the main window as I experienced previously. I tried to reproduce this, but to no avail. I don't know what triggered it.
Keep up the good work, it really good.
You do not need to configure with python or perl. But I don't know what you need to do to get those plugins working. I think I remember Ted saying he was going to disable plugins for a while while he rearchitectured things. I was hoping that he would fill us in when he gets back.
If you do get it to work please record your steps on the wiki: http://inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking
I did not get the three plugins working. I think they are not installed properly, which might be the effect of disabling them.
Thanks,
Wolfi
Wolfram Quester wrote:
On Mon, Jun 20, 2005 at 08:26:39AM -0500, aaron@...749... wrote: Kochify gives me an error on the console: No preferences for Effect
That message isn't an error. It is just informational. Kochify has no user specifiable preferences, and therefore no autogui window. Kochify fails because you must load a path first with Kochify (load). The effect is then that Kochify replaces each segment of the second path with the first.
My solution for this would be to have a multiline text label for usage information displayed on the autogui window.
The Fret Find things give me Scala scale description file expected. Extension::Script: Unknown error for pclose : Success This should be more user friendly and perhaps an example description file could be provided.
Again it would be nice to include usage information on the gui. This rather useless effect requires the path to a microtonal scale description file. The format belongs to an awesome program called Scala. The a description of the format can be found here:
http://www.xs4all.nl/~huygensf/scala/scl_format.html
For this effect I would also find use for either a file selection widget or a multiline text input widget. I started collecting the features I want for effects on the wiki. Hopefully they will turn into real RFE's and then real features. But for now I'm just throwing some ideas out there:
http://www.inkscape.org/cgi-bin/wiki.pl?ExtensionArchitectureProposals
Using dropshadow on a Lindenmayer curve gives me sometimes just a copy of the curve, sometimes a great shadow.
I have honestly never tried that. The complex paths generated by Lindenmayer systems tend to overwhelm my computer even without a shadow. :) But I think I would have a difficult time distinguishing between one line art object's copy and its shadow. What is the difference?
While experimenting I had one crash. I repeatedly used some effects and inkscape crashed, but without closing the main window as I experienced previously. I tried to reproduce this, but to no avail. I don't know what triggered it.
I experience this quite often and mostly while debugging new effects. But I have never been able to find steps to reproduce it. For me, crashes seem to be much less frequent when running through gdb, so it is hard to make a backtrace too.
You do not need to configure with python or perl. But I don't know what you need to do to get those plugins working. I think I remember Ted saying he was going to disable plugins for a while while he rearchitectured things. I was hoping that he would fill us in when he gets back.
If you do get it to work please record your steps on the wiki: http://inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking
I did not get the three plugins working. I think they are not installed properly, which might be the effect of disabling them.
Ted? Any ideas?
Aaron Spike
Quoting aaron@...749...:
I experience this quite often and mostly while debugging new effects.
But I have never been able to find steps to reproduce it. For me, crashes seem to be much less frequent when running through gdb, so it is hard to make a backtrace too.
I know there are some premature frees of (non-garbage-collector-managed) memory lurking in the codebase, but I've been unable to localize them yet.
There's a bug assigned to me -- I forget which one exactly, but it's got a file attached where if you follow the instructions in the bug you can just watch elements of the display fill with "junk" as memory is (wrongly) reused for other things.
The visible junk is showing up in the paint server buffers, but unfortunately that doesn't mean the bug is in the paint server code...
It could just mean that some other unreleated part of the code freed memory prematurely, and continued to use that memory even after it had subsequently been given to a paint server.
Frankly, I suspect livarot (don't I always?), but the only part of the code that I can actually rule out is the stuff that uses the garbage collector.
[ The garbage collector maintains a separate heap from the system heap that the paint servers use, and this sort of erroneous reuse isn't generally possible across heaps. ]
I'd really like to nail this stuff down before the release, because I'm sure it's behind an awful lot of obscure crashes. :/
[to all on the list] Any ideas for further tracking things down?
-mental
[ The garbage collector maintains a separate heap from the system heap that the paint servers use, and this sort of erroneous reuse isn't generally possible across heaps. ]
[to all on the list] Any ideas for further tracking things down?
Naive answer: Use something like efence?
I really don't know if such libraries can help with code of this league but I'm hoping someone can tell me why not.
ralf
Quoting Ralf Stephan <ralf@...748...>:
[ The garbage collector maintains a separate heap from the
system
heap that the paint servers use, and this sort of erroneous
reuse
isn't generally possible across heaps. ]
[to all on the list] Any ideas for further tracking things
down?
Naive answer: Use something like efence?
I really don't know if such libraries can help with code of this league but I'm hoping someone can tell me why not.
efence or valgrind _might_ catch it if the memory remained un-reused for a long period of time. The problem, though, is that most of the time the memory is getting quickly allocated again, so accesses to it look valid. Catching it would be a matter of (slim) luck. :/
Maybe one possibility would be to modify efence to mark freed memory as inaccessible but never actually return it to the pool for re-allocation...
Anyone interested? I could do it myself, but I can't promise to have time to do it soon.
-mental
Maybe one possibility would be to modify efence to mark freed memory as inaccessible but never actually return it to the pool for re-allocation...
This may not be necessary since inkscape in valgrind-2.4.0 already aborts on startup with
==19853== Addrcheck, a fine-grained address checker for x86-linux. ==19853== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==19853== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==19853== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==19853== ==19853== My PID = 19853, parent PID = 7747. Prog and args are: ==19853== inkscape ==19853== For more details, rerun with: -v ==19853== ==19853== Invalid read of size 4 ==19853== at 0x34E12713: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E12398: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B6F4: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B321: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E15099: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E10B34: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E10C90: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E10F84: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x811D2AC: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:72) ==19853== by 0x83A27A9: sp_repr_new(char const*) (gc-managed.h:55) ==19853== by 0x839F461: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19853== by 0x839F285: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19853== Address 0x9C600014 is not stack'd, malloc'd or (recently) free'd ==19853== ==19853== Process terminating with default action of signal 11 (SIGSEGV) ==19853== Bad permissions for mapped region at address 0x9C600014 [...] ==19853== ==19853== Invalid write of size 4 ==19853== at 0x34F31F9B: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34F32358: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34F31ED5: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34F3F163: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34F3FCE0: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x35020885: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x350209AE: __libc_freeres (in /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34144A04: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:55) ==19853== by 0x9C5FE26F: ??? ==19853== by 0x34E12398: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B6F4: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B321: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19853== Address 0x3527DF98 is 0 bytes inside a block of size 120 free'd ==19853== at 0x3414AB10: free (vg_replace_malloc.c:152) ==19853== by 0x34F32AC5: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34FEC4DE: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34FEC4FA: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34FEC385: tdestroy (in /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x35020502: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x350209AE: __libc_freeres (in /lib/tls/i686/cmov/libc-2.3.2.so) ==19853== by 0x34144A04: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:55) ==19853== by 0x9C5FE26F: ??? ==19853== by 0x34E12398: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B6F4: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19853== by 0x34E0B321: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19853== ==19853== ERROR SUMMARY: 26 errors from 14 contexts (suppressed: 0 from 0) ==19853== malloc/free: in use at exit: 308402 bytes in 6039 blocks. ==19853== malloc/free: 10043 allocs, 4004 frees, 720603 bytes allocated. ==19853== For counts of detected errors, rerun with: -v ==19853== searching for pointers to 6039 not-freed blocks. ==19853== checked 2484332 bytes. ==19853== ==19853== LEAK SUMMARY: ==19853== definitely lost: 156 bytes in 11 blocks. ==19853== possibly lost: 7816 bytes in 25 blocks. ==19853== still reachable: 300430 bytes in 6003 blocks. ==19853== suppressed: 0 bytes in 0 blocks. ==19853== Use --leak-check=full to see details of leaked memory.
Quoting Ralf Stephan <ralf@...748...>:
Maybe one possibility would be to modify efence to mark freed memory as inaccessible but never actually return it to the pool for re-allocation...
This may not be necessary since inkscape in valgrind-2.4.0 already aborts on startup with... [snip]
No, the invalid reads (in the GC_*mark* functions specifically -- other invalid reads wouldn't be OK) are a necessary rseult of performing conservative garbage collection. You can expect them during normal operation.
However, the invalid write resulting in a crash is the result of an incompatibility between valgrind and recent versions of libgc.
[ late-model versions of libgc rely on /proc/self/maps, but valgrind remaps memory in ways which are not reflected there ]
Basically you will have to disable libgc to use valgrind. Try again after setting the _INKSCAPE_GC environment variable to "disable".
-mental
Basically you will have to disable libgc to use valgrind. Try again after setting the _INKSCAPE_GC environment variable to "disable".
Thanks. Suppressing those errors I get now very interesting results I want to share with you. First, people trying to attempt this should know they need a GHz machine with 512 MB RAM as even only AddrCheck together with inkscape needs 400 MB. Second, you need a suppressions file, for the reasons outlined by mental, which is appended.
Now, only starting inkscape up and quitting, the output from $ valgrind --tool=addrcheck --suppressions=s --leak-check=full inkscape
follows. I'm not sure if I'm the one to fix all these so please give me some feedback if you see at once where the problem is, or if you intend to fix it so I can concentrate on the unknown ones.
==13185== Addrcheck, a fine-grained address checker for x86-linux. ==13185== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==13185== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==13185== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13185== ==13185== My PID = 13185, parent PID = 7595. Prog and args are: ==13185== inkscape ==13185== For more details, rerun with: -v ==13185== ==13185== ==13185== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 2) ==13185== malloc/free: in use at exit: 10281070 bytes in 96946 blocks. ==13185== malloc/free: 441264 allocs, 344318 frees, 57403229 bytes allocated. ==13185== For counts of detected errors, rerun with: -v ==13185== searching for pointers to 96946 not-freed blocks. ==13185== checked 12185444 bytes. ==13185== ==13185== 24 bytes in 1 blocks are possibly lost in loss record 46 of 428 ==13185== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==13185== by 0x34438E45: Gdk::Screen_Class::wrap_new(_GObject*) (in /usr/lib/libgdkmm-2.4.so.1.0.19) ==13185== by 0x344EE895: (within /usr/lib/libglibmm-2.4.so.1.0.13) ==13185== by 0x344EEAE2: Glib::wrap_auto(_GObject*, bool) (in /usr/lib/libglibmm-2.4.so.1.0.13) ==13185== by 0x34438C8C: Glib::wrap(_GdkScreen*, bool) (in /usr/lib/libgdkmm-2.4.so.1.0.19) ==13185== by 0x3434DA0B: Gtk::Widget_Class::screen_changed_callback(_GtkWidget*, _GdkScreen*) (in /usr/lib/libgtkmm-2.4.so.1.0.19) ==13185== by 0x34CE063A: g_cclosure_marshal_VOID__OBJECT (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CCF5BE: (within /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CCF350: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CDF26F: (within /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CDE8F0: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CDEB74: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== ==13185== ==13185== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 227 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x34FFCE1C: (within /lib/tls/i686/cmov/libc-2.3.2.so) ==13185== by 0x34FFC72D: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.3.2.so) ==13185== by 0x34154A62: ??? ==13185== by 0x34FBFE2B: getpwuid_r (in /lib/tls/i686/cmov/libc-2.3.2.so) ==13185== by 0x34D4848B: (within /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D48951: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34648F9C: (within /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34649533: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34613B60: (within /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34613C5A: (within /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34D32ED9: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== ==13185== ==13185== 39 bytes in 1 blocks are possibly lost in loss record 228 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x811D31A: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:75) ==13185== by 0x83A8D31: Inkscape::Util::SharedCStringPtr::copy(char const*, unsigned) (gc-core.h:177) ==13185== by 0x83A8CA3: Inkscape::Util::SharedCStringPtr::copy(char const*) (shared-c-string-ptr.cpp:25) ==13185== by 0x83A288B: sp_repr_new_text(char const*) (text-node.h:27) ==13185== by 0x839F40E: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:444) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F285: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==13185== by 0x839EE2E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==13185== by 0x838C148: Inkscape::Extension::build_from_mem(char const*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:466) ==13185== ==13185== ==13185== 96 bytes in 3 blocks are possibly lost in loss record 258 of 428 ==13185== at 0x3414B07B: realloc (vg_replace_malloc.c:196) ==13185== by 0x34D2CBB6: g_realloc (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3E463: (within /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3E9B7: g_string_insert_len (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3EC10: g_string_append_len (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D1A697: (within /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D1A850: g_build_filename (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x8123DED: profile_path(char const*) (inkscape.cpp:1365) ==13185== by 0x828F956: sp_icon_image_load_svg(char const*, unsigned, unsigned) (stl_list.h:748) ==13185== by 0x828E347: sp_icon_image_load(SPIcon*, char const*) (icon.cpp:327) ==13185== by 0x828DDFD: sp_icon_expose(_GtkWidget*, _GdkEventExpose*) (icon.cpp:189) ==13185== by 0x34616BC9: _gtk_marshal_BOOLEAN__BOXED (in /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== ==13185== ==13185== 120 bytes in 1 blocks are possibly lost in loss record 266 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x34F90AFE: strdup (in /lib/tls/i686/cmov/libc-2.3.2.so) ==13185== by 0x82C892D: sp_action_new(SPView*, char const*, char const*, char const*, char const*, Inkscape::Verb*) (action.cpp:95) ==13185== by 0x8286122: sp_button_new_from_data(GtkIconSize, SPButtonType, SPView*, char const*, char const*, _GtkTooltips*) (button.cpp:329) ==13185== by 0x81E7638: sp_dropper_toolbox_new(SPDesktop*) (toolbox.cpp:2470) ==13185== by 0x81E0FFB: setup_aux_toolbox(_GtkWidget*, SPDesktop*) (toolbox.cpp:603) ==13185== by 0x81E0C96: toolbox_set_desktop(_GtkWidget*, SPDesktop*, void (*)(_GtkWidget*, SPDesktop*), void (*)(SPDesktop*, SPEventContext*, _GtkWidget*)) (toolbox.cpp:549) ==13185== by 0x81E0AB2: sp_aux_toolbox_set_desktop(_GtkWidget*, SPDesktop*) (toolbox.cpp:518) ==13185== by 0x819C805: sp_desktop_widget_new(SPNamedView*) (desktop.cpp:1425) ==13185== by 0x811E9B8: sp_file_new(char const*) (file.cpp:105) ==13185== by 0x811EA9B: sp_file_new_default() (file.cpp:118) ==13185== by 0x8117505: sp_main_gui(int, char const**) (main.cpp:530) ==13185== ==13185== ==13185== 157 bytes in 9 blocks are possibly lost in loss record 276 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x34D2CAD6: g_malloc (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3BA5B: g_strdup (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x838D1F8: Inkscape::Extension::Input::Input(Inkscape::XML::Node*, Inkscape::Extension::Implementation::Implementation*) (repr.h:175) ==13185== by 0x838BF61: Inkscape::Extension::build_from_reprdoc(Inkscape::XML::Document*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:410) ==13185== by 0x838C159: Inkscape::Extension::build_from_mem(char const*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:467) ==13185== by 0x8399438: Inkscape::Extension::Internal::GdkpixbufInput::init() (gdkpixbuf-input.cpp:148) ==13185== by 0x83878D7: Inkscape::Extension::init() (init.cpp:145) ==13185== by 0x81220AB: inkscape_application_init(char const*, int) (inkscape.cpp:596) ==13185== by 0x81174F9: sp_main_gui(int, char const**) (main.cpp:521) ==13185== by 0x81EEB27: Inkscape::NSApplication::Application::run() (application.cpp:134) ==13185== by 0x811708F: main (main.cpp:418) ==13185== ==13185== ==13185== 581 bytes in 32 blocks are definitely lost in loss record 318 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x34D2CAD6: g_malloc (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D47FF6: g_path_get_basename (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x8125919: sp_menu_append_new_templates(_GtkWidget*, SPView*) (interface.cpp:696) ==13185== by 0x81252F0: sp_ui_menu_append_submenu(_GtkMenu*, SPView*, void (*)(_GtkWidget*, SPView*), char const*, char const*, char const*) (interface.cpp:567) ==13185== by 0x8125CAF: sp_ui_file_menu(_GtkMenu*, SPDocument*, SPView*) (interface.cpp:761) ==13185== by 0x8126AC8: sp_ui_main_menubar(SPView*) (interface.cpp:1150) ==13185== by 0x819C781: sp_desktop_widget_new(SPNamedView*) (desktop.cpp:1418) ==13185== by 0x811E9B8: sp_file_new(char const*) (file.cpp:105) ==13185== by 0x811EA9B: sp_file_new_default() (file.cpp:118) ==13185== by 0x8117505: sp_main_gui(int, char const**) (main.cpp:530) ==13185== by 0x81EEB27: Inkscape::NSApplication::Application::run() (application.cpp:134) ==13185== ==13185== ==13185== 1036 bytes in 28 blocks are possibly lost in loss record 336 of 428 ==13185== at 0x3414AF81: calloc (vg_replace_malloc.c:175) ==13185== by 0x34D2CB45: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34CE1491: (within /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CE1789: (within /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CE85DF: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CE86DE: g_type_init (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x347D8CAF: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.600.4) ==13185== by 0x346139FB: (within /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34613C29: (within /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34D3362C: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34613EB2: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x34613EE5: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== ==13185== ==13185== 1328 bytes in 83 blocks are possibly lost in loss record 340 of 428 ==13185== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==13185== by 0x83A35D9: Inkscape::XML::SimpleDocument::_initBindings() (simple-document.cpp:24) ==13185== by 0x83A2B8D: sp_repr_document_new(char const*) (simple-document.h:27) ==13185== by 0x83A2CFE: sp_repr_document_new_list(_GSList*) (repr.cpp:94) ==13185== by 0x839F1C8: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:390) ==13185== by 0x839ED64: sp_repr_read_file(char const*, char const*) (repr-io.cpp:258) ==13185== by 0x838C0BF: Inkscape::Extension::build_from_file(char const*) (system.cpp:446) ==13185== by 0x8387A91: Inkscape::Extension::build_module_from_dir(char const*) (init.cpp:204) ==13185== by 0x83878C4: Inkscape::Extension::init() (stl_vector.h:501) ==13185== by 0x81220AB: inkscape_application_init(char const*, int) (inkscape.cpp:596) ==13185== by 0x81174F9: sp_main_gui(int, char const**) (main.cpp:521) ==13185== by 0x81EEB27: Inkscape::NSApplication::Application::run() (application.cpp:134) ==13185== ==13185== ==13185== 2633 (2600 direct, 33 indirect) bytes in 36 blocks are definitely lost in loss record 355 of 428 ==13185== at 0x3414AF81: calloc (vg_replace_malloc.c:175) ==13185== by 0x34D2CB45: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34CE4111: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CD2267: (within /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CD1A99: g_object_newv (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CD2211: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x34CD17AF: g_object_new (in /usr/lib/libgobject-2.0.so.0.600.3) ==13185== by 0x346B6D13: gtk_tooltips_new (in /usr/lib/libgtk-x11-2.0.so.0.600.4) ==13185== by 0x81ED037: sp_select_toolbox_spinbutton(char*, char*, float, _GtkWidget*, _GtkWidget*, char*, int) (select-toolbar.cpp:247) ==13185== by 0x81EDD5E: sp_select_toolbox_new(SPDesktop*) (select-toolbar.cpp:410) ==13185== by 0x81E0FFB: setup_aux_toolbox(_GtkWidget*, SPDesktop*) (toolbox.cpp:603) ==13185== by 0x81E0C96: toolbox_set_desktop(_GtkWidget*, SPDesktop*, void (*)(_GtkWidget*, SPDesktop*), void (*)(SPDesktop*, SPEventContext*, _GtkWidget*)) (toolbox.cpp:549) ==13185== ==13185== ==13185== 9006 (960 direct, 8046 indirect) bytes in 15 blocks are definitely lost in loss record 370 of 428 ==13185== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==13185== by 0x838BF4C: Inkscape::Extension::build_from_reprdoc(Inkscape::XML::Document*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:410) ==13185== by 0x838C159: Inkscape::Extension::build_from_mem(char const*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:467) ==13185== by 0x8399438: Inkscape::Extension::Internal::GdkpixbufInput::init() (gdkpixbuf-input.cpp:148) ==13185== by 0x83878D7: Inkscape::Extension::init() (init.cpp:145) ==13185== by 0x81220AB: inkscape_application_init(char const*, int) (inkscape.cpp:596) ==13185== by 0x81174F9: sp_main_gui(int, char const**) (main.cpp:521) ==13185== by 0x81EEB27: Inkscape::NSApplication::Application::run() (application.cpp:134) ==13185== by 0x811708F: main (main.cpp:418) ==13185== ==13185== ==13185== 3424 bytes in 84 blocks are definitely lost in loss record 378 of 428 ==13185== at 0x3414B07B: realloc (vg_replace_malloc.c:196) ==13185== by 0x34D2CBB6: g_realloc (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3E463: (within /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3E9B7: g_string_insert_len (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D3EC10: g_string_append_len (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D1A697: (within /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x34D1A850: g_build_filename (in /usr/lib/libglib-2.0.so.0.600.3) ==13185== by 0x8125965: sp_menu_append_new_templates(_GtkWidget*, SPView*) (interface.cpp:700) ==13185== by 0x81252F0: sp_ui_menu_append_submenu(_GtkMenu*, SPView*, void (*)(_GtkWidget*, SPView*), char const*, char const*, char const*) (interface.cpp:567) ==13185== by 0x8125CAF: sp_ui_file_menu(_GtkMenu*, SPDocument*, SPView*) (interface.cpp:761) ==13185== by 0x8126AC8: sp_ui_main_menubar(SPView*) (interface.cpp:1150) ==13185== by 0x819C781: sp_desktop_widget_new(SPNamedView*) (desktop.cpp:1418) ==13185== ==13185== ==13185== 6840 bytes in 2 blocks are possibly lost in loss record 385 of 428 ==13185== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==13185== by 0x34EAEA5A: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EAE96C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EAE667: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EB3FF7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EB40CD: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EB1CEC: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x34EB21F1: std::string::append(char const*, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==13185== by 0x344EB04F: Glib::ustring::operator+=(unsigned) (in /usr/lib/libglibmm-2.4.so.1.0.13) ==13185== by 0x8164DB2: sp_string_read_content(SPObject*) (sp-string.cpp:147) ==13185== by 0x8164C53: sp_string_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (sp-string.cpp:106) ==13185== by 0x8151D8D: sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (sp-object.cpp:668) ==13185== ==13185== ==13185== 14494 bytes in 968 blocks are definitely lost in loss record 386 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x811D31A: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:75) ==13185== by 0x83A8D31: Inkscape::Util::SharedCStringPtr::copy(char const*, unsigned) (gc-core.h:177) ==13185== by 0x83A8CA3: Inkscape::Util::SharedCStringPtr::copy(char const*) (shared-c-string-ptr.cpp:25) ==13185== by 0x83A288B: sp_repr_new_text(char const*) (text-node.h:27) ==13185== by 0x839F40E: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:444) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F285: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==13185== by 0x839ED64: sp_repr_read_file(char const*, char const*) (repr-io.cpp:258) ==13185== by 0x838C0BF: Inkscape::Extension::build_from_file(char const*) (system.cpp:446) ==13185== by 0x8387A91: Inkscape::Extension::build_module_from_dir(char const*) (init.cpp:204) ==13185== ==13185== ==13185== 23105 (10824 direct, 12281 indirect) bytes in 136 blocks are definitely lost in loss record 388 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x811D2AC: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:72) ==13185== by 0x83A27A9: sp_repr_new(char const*) (gc-managed.h:55) ==13185== by 0x83A2C4A: sp_repr_document_new(char const*) (repr.cpp:82) ==13185== by 0x83A2CFE: sp_repr_document_new_list(_GSList*) (repr.cpp:94) ==13185== by 0x839F1C8: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:390) ==13185== by 0x839ED64: sp_repr_read_file(char const*, char const*) (repr-io.cpp:258) ==13185== by 0x838C0BF: Inkscape::Extension::build_from_file(char const*) (system.cpp:446) ==13185== by 0x8387A91: Inkscape::Extension::build_module_from_dir(char const*) (init.cpp:204) ==13185== by 0x83878C4: Inkscape::Extension::init() (stl_vector.h:501) ==13185== by 0x81220AB: inkscape_application_init(char const*, int) (inkscape.cpp:596) ==13185== by 0x81174F9: sp_main_gui(int, char const**) (main.cpp:521) ==13185== ==13185== ==13185== 284340 bytes in 3087 blocks are possibly lost in loss record 422 of 428 ==13185== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13185== by 0x811D2AC: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:72) ==13185== by 0x83A287A: sp_repr_new_text(char const*) (gc-managed.h:55) ==13185== by 0x839F40E: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:444) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F4A5: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:470) ==13185== by 0x839F285: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==13185== by 0x839EE2E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==13185== by 0x838C148: Inkscape::Extension::build_from_mem(char const*, Inkscape::Extension::Implementation::Implementation*) (system.cpp:466) ==13185== by 0x8399438: Inkscape::Extension::Internal::GdkpixbufInput::init() (gdkpixbuf-input.cpp:148) ==13185== by 0x83878D7: Inkscape::Extension::init() (init.cpp:145) ==13185== ==13185== LEAK SUMMARY: ==13185== definitely lost: 32919 bytes in 1272 blocks. ==13185== indirectly lost: 20480 bytes in 460 blocks. ==13185== possibly lost: 293980 bytes in 3215 blocks. ==13185== still reachable: 9933691 bytes in 91999 blocks. ==13185== suppressed: 0 bytes in 0 blocks. ==13185== Reachable blocks (those to which a pointer was found) are not shown. ==13185== To see them, rerun with: --show-reachable=yes
Addendum: the amount of memory allocated and growing shown by top when I cycle through 'load keys.svg; New file; close keys.svg' is nearly the same which valgrind shows me on this block:
==13354== ==13354== 23251088 (2212104 direct, 21038984 indirect) bytes in 8917 blocks are definitely lost in loss record 470 of 474 ==13354== at 0x3414A5A9: malloc (vg_replace_malloc.c:130) ==13354== by 0x811D2AC: operator new(unsigned, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy, void (*)(void*, void*), void*) (gc-core.h:72) ==13354== by 0x83A27A9: sp_repr_new(char const*) (gc-managed.h:55) ==13354== by 0x83A2C4A: sp_repr_document_new(char const*) (repr.cpp:82) ==13354== by 0x83A2CFE: sp_repr_document_new_list(_GSList*) (repr.cpp:94) ==13354== by 0x839F1C8: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:390) ==13354== by 0x839ED64: sp_repr_read_file(char const*, char const*) (repr-io.cpp:258) ==13354== by 0x838C0BF: Inkscape::Extension::build_from_file(char const*) (system.cpp:446) ==13354== by 0x8387A91: Inkscape::Extension::build_module_from_dir(char const*) (init.cpp:204) ==13354== by 0x83878C4: Inkscape::Extension::init() (stl_vector.h:501) ==13354== by 0x81220AB: inkscape_application_init(char const*, int) (inkscape.cpp:596) ==13354== by 0x81174F9: sp_main_gui(int, char const**) (main.cpp:521)
A question: wouldn't a forced garbage collection at close time cure the situation, as most people have reported problems when closing/opening documents?
ralf
Quoting Ralf Stephan <ralf@...748...>:
Addendum: the amount of memory allocated and growing shown by top when I cycle through 'load keys.svg; New file; close keys.svg' is nearly the same which valgrind shows me on this block:
This should be an expected consequence of disabling garbage collection.
You will simply have to ignore leaks where you see an allocator taking Inkscape::GC::ScanPolicy or Inkscape::GC::CollectionPolicy in the call chain. It should be possible to write a suppression profile to do this.
Note that most Inkscape subsystems do not use the garbage-collected heap, so you can still get useful results for other memory.
A question: wouldn't a forced garbage collection at close time cure the situation, as most people have reported problems when closing/opening documents?
No (it's been tried). The leaks on document close are in manually managed memory.
-mental
This should be an expected consequence of disabling garbage collection.
A shame I had to be told this ;)
You will simply have to ignore leaks where you see an allocator taking Inkscape::GC::ScanPolicy or Inkscape::GC::CollectionPolicy in the call chain. It should be possible to write a suppression profile to do this.
That would be this one: { GC_malloc Addrcheck:Leak fun:malloc fun:_ZnwjN8Inkscape2GC10ScanPolicyENS0_16CollectionPolicyEPFvPvS3_ES3_ }
Note that most Inkscape subsystems do not use the garbage-collected heap, so you can still get useful results for other memory.
So I did. The two most leaky blocks are appended below. I still have to get more familiar with the code to send a patch for these.
Incidentally, while it's good to solve memory leaks, the problem I've been trying to diagnose is the one in this bug: http://sourceforge.net/tracker/index.php?func=detail&atid=604306&aid... The problem, if you can track it down, should manifest (unfortunately probably only very intermittently) as an invalid write to freed memory.
I will try to reproduce it but first want to do the more visible ones.
ralf
==11587== 84120 bytes in 5 blocks are possibly lost in loss record 436 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAEA5A: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE96C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE667: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB3FF7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB40CD: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB1CEC: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB21F1: std::string::append(char const*, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x344EB04F: Glib::ustring::operator+=(unsigned) (in /usr/lib/libglibmm-2.4.so.1.0.13) ==11587== by 0x8164DC2: sp_string_read_content(SPObject*) (sp-string.cpp:147) ==11587== by 0x8164C63: sp_string_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (sp-string.cpp:106) ==11587== by 0x8151D9D: sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (sp-object.cpp:668) ==11587== ==11587== ==11587== 120616 bytes in 303 blocks are possibly lost in loss record 444 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAE5F8: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x834279F: _ZNSt6vectorIN5Shape8dg_pointESaIS1_EE20_M_allocate_and_copyIN9__gnu_cxx17__normal_iteratorIPKS1_S3_EEEEPS1_jT_SB_ (stl_alloc.h:232) ==11587== by 0x833EB9C: std::vector<Shape::dg_point, std::allocatorShape::dg_point >::operator=(std::vector<Shape::dg_point, std::allocatorShape::dg_point > const&) (stl_vector.h:363) ==11587== by 0x83393DC: Shape::Copy(Shape*) (Shape.cpp:264) ==11587== by 0x82B16DB: nr_arena_shape_update_stroke(NRArenaShape*, NRGC*) (nr-arena-shape.cpp:564) ==11587== by 0x82B202A: nr_arena_shape_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-shape.cpp:660) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658) ==11587== by 0x82AEEF6: nr_arena_group_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-group.cpp:198) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658) ==11587== by 0x82AEEF6: nr_arena_group_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned) (nr-arena-group.cpp:198) ==11587== by 0x82AD103: nr_arena_item_invoke_render(NRArenaItem*, NRRectL const*, NRPixBlock*, unsigned) (nr-arena-item.cpp:658)
Why not pipe the C++ allocations into the GC as well as doing a search and replace of the remaining malloc()'s? This way everything lives in libgc and can be checked from there too.
Naively, ralf
On Sun, 2005-06-26 at 17:31 +0200, Ralf Stephan wrote:
Why not pipe the C++ allocations into the GC as well as doing a search and replace of the remaining malloc()'s? This way everything lives in libgc and can be checked from there too.
Mainly because of bad interactions with libraries. They'll still be using malloc(), after all, and we'd have to add extra code to make sure that the garbage collector didn't prematurely collect objects while a malloc()ed object from some library (notably GTK) still held references to it. It would be very, very difficult to get right.
(What we do right now is have a reference-counted "shim" (Inkscape::GC::Anchored) which can be used to deal with references from non-GC-aware objects. But that's easy to deal with when we control those objects. Less so when those objects belong to other libraries...)
An alternative would be to use libgc in malloc-replacement mode, so everybody uses it. No code changes necessary (theoretically...). One problem -- libraries like gdk use malloc() to allocate large RGBA bitmaps. RGBA pixels are statistically likely to look like valid pointers (when you have a lot of them of various colors).
It'd be nice if there were some way to force gdk to use GC_malloc_atomic() for those bitmaps [to indicate to the collector that it's not supposed to scan for pointers there], but since there isn't, it'd basically just render the garbage collector useless.
(Actually in malloc-replacement mode we'd also have to disable GC::Anchored, or we'd have problems with reference cycles)
We do plan on increasing the amount of code that uses the collector, but experiences so far have shown that there are enough subtle issues involved that a simple search-and-replace isn't safe.
-mental
On Sun, 2005-06-26 at 08:37 +0200, Ralf Stephan wrote:
That would be this one: { GC_malloc Addrcheck:Leak fun:malloc fun:_ZnwjN8Inkscape2GC10ScanPolicyENS0_16CollectionPolicyEPFvPvS3_ES3_ }
Hmm, that works? When garbage collection is disabled, operator new always calls malloc(), not GC_malloc()...
-mental
That would be this one: { GC_malloc Addrcheck:Leak fun:malloc fun:_ZnwjN8Inkscape2GC10ScanPolicyENS0_16CollectionPolicyEPFvPvS3_ES3_ }
Hmm, that works? When garbage collection is disabled, operator new always calls malloc(), not GC_malloc()...
Yes. The first line is simply a name, the last two are significant.
ralf
On Sun, 2005-06-26 at 08:37 +0200, Ralf Stephan wrote:
I will try to reproduce it but first want to do the more visible ones.
OK.
ralf
==11587== 84120 bytes in 5 blocks are possibly lost in loss record 436 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAEA5A: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE96C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EAE667: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB3FF7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB40CD: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB1CEC: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x34EB21F1: std::string::append(char const*, unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x344EB04F: Glib::ustring::operator+=(unsigned) (in /usr/lib/libglibmm-2.4.so.1.0.13) ==11587== by 0x8164DC2: sp_string_read_content(SPObject*) (sp-string.cpp:147) ==11587== by 0x8164C63: sp_string_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (sp-string.cpp:106) ==11587== by 0x8151D9D: sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (sp-object.cpp:668)
This would tend to suggest that SPString::string's destructor isn't being called... but it should be... is the SPString itself getting leaked perhaps?
[ actually, if we're leaking entire documents after close like some suspect, that would do it... ]
==11587== 120616 bytes in 303 blocks are possibly lost in loss record 444 of 472 ==11587== at 0x3414A733: operator new(unsigned) (vg_replace_malloc.c:132) ==11587== by 0x34EAE5F8: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==11587== by 0x834279F: _ZNSt6vectorIN5Shape8dg_pointESaIS1_EE20_M_allocate_and_copyIN9__gnu_cxx17__normal_iteratorIPKS1_S3_EEEEPS1_jT_SB_ (stl_alloc.h:232) ==11587== by 0x833EB9C: std::vector<Shape::dg_point, std::allocatorShape::dg_point >::operator=(std::vector<Shape::dg_point, std::allocatorShape::dg_point > const&) (stl_vector.h:363) ==11587== by 0x83393DC: Shape::Copy(Shape*) (Shape.cpp:264)
AHHH... this is the livarot leak I've been suspecting for so long. I'm not quite sure of the cause yet though...
-mental
Incidentally, while it's good to solve memory leaks, the problem I've been trying to diagnose is the one in this bug:
http://sourceforge.net/tracker/index.php?func=detail&atid=604306&aid...
It's the result of the opposite problem from memory leaks: memory getting prematurely freed.
I know it's in the manually managed system heap (versus the garbage collector's), because the corruption is only showing up in memory allocated from the system heap.
The problem, if you can track it down, should manifest (unfortunately probably only very intermittently) as an invalid write to freed memory.
-mental
aaron@...749... wrote:
You do not need to configure with python or perl. But I don't know what you need to do to get those plugins working. I think I remember Ted saying he was going to disable plugins for a while while he rearchitectured things. I was hoping that he would fill us in when he gets back.
If you do get it to work please record your steps on the wiki: http://inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking
I did not get the three plugins working. I think they are not installed properly, which might be the effect of disabling them.
Ted? Any ideas?
Those effects were the ones that were implemented as plugins -- and to be entirely honest -- plugins didn't work as well as I thought that they did. The entire plugins implementation has been removed, waiting for Ishmal's DOM stuff to make them more reasonable. I imagine that the same error won't occur with CVS where they are now built into the code base.
Sorry to take so long on this, I'm trying to catch up on list mail...
--Ted
On 6/20/05, Wolfram Quester <wolfi@...111...> wrote:
I have the problem with the effects menu too. (debian unstable, cvs last week). I deleted .inkscape in my homedir and had a look in the dialog you mention but I don't see any possibility to enable the menu there (see attached screenshot). I also have problems with 3 extensions, but I don't know yet if I should configure --with-python --with-perl to get them working. I update from cvs atm an will recompile soon. The affacted extensions are:
Extension "Blur Edge" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: bluredge
Extension "GIMP Gradients" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: gimpgrad
Extension "Grid" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: grid
Exactly same error, FC4/extras + a little bit livna.org packages (tu turn on MP3/DVD only) here
Alexandre
participants (8)
-
unknown＠example.com -
Alexandre Prokoudine -
Bryce Harrington -
Lucas Vieites -
MenTaLguY -
Ralf Stephan -
Ted Gould -
Wolfram Quester