i wrote up a patch ( https://bugs.launchpad.net/inkscape/+bug/1092374/comments/11 ) for https://bugs.launchpad.net/inkscape/+bug/1092374
but as you can see from the comment (hopefully not the patch itself) i dont have much experience with c++, gtk or inkscape programming, so i really want to avoid the potential of having created a memory leak with that. if someone could take a look and enlighten me a bit i would appreciate it. last thing i want is to be making inkscape a slow hog through my little fixes
-- View this message in context: http://inkscape.13.x6.nabble.com/question-about-memory-leaks-tp4966734.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 25-Apr-2013 07:27, Martin Owens wrote:
On Thu, 2013-04-25 at 00:29 -0700, insaner wrote:
potential of having created a memory leak with that.
I can only see that a GtkWindow is being created but not freed. Everything else looks sensible to me. CPP veterans would do a better scan though :-)
It really does not matter how veteran you are, there is always the possibility of generating a memory leak. The only way to really be sure that there is not one is to use diagnostic tools. For instance, I run inkscape under valgrind, exercise the section of code which has been modified, and then exit normally. Afterwards I usually grep for the names of the files I have been working on in the log file. Ideally they would not appear. In practice since there are already many sections that leak, if you call one of those you may introduce some leakage that is, essentially, outside of your code. Anything else, you fix. Valgrind is good about telling you which pieces of memory were left dangling and where they were first allocated.
The commands I use are:
export _INKSCAPE_GC=disable valgrind --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes src/inkscape \ >/tmp/vg.log 2>&1
The call list can be exceedingly deep, but typically you only need the last few if you are looking for a leak you just introduced, and the log file is easier to deal with with shorter stack lists.
On my linux test system it takes 4-5 minutes for inkscape to start fully when running this way, depending on what the GUI looked like when it last closed, and that is only if I am _very_ careful not to let another window or the mouse overlap it while it is trying to start. (Wave the mouse over it while it is trying to start and it will take forever to do so!) What I generally do is open a squat console window at the bottom of the screen and run "top" there, and then start inkscape using the above method from another console window in the upper left corner of the screen. I do not touch the Inkscape GUI until the CPU usage on that process drops down to 0 or 1%. The squat window is far enough down that it does not intersect the nascent Inkscape GUI window.
Of course you need to compile with -g for the output to be useful, but I think that is the default.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Martin Owens-2 wrote
On Thu, 2013-04-25 at 00:29 -0700, insaner wrote:
potential of having created a memory leak with that.
I can only see that a GtkWindow is being created but not freed. Everything else looks sensible to me. CPP veterans would do a better scan though :-)
hi martin owens, thanks for the reply. i dont however see where the gtkwindow is being created.
my concern is with the creating of the pointer: prev_event_context = event_context;
as i'm not sure if/when each event_context gets free'd. if it ever does (a grep couldnt fint it) it might cause a segfault. since i never saw a free(event_context) i figured i didnt have to free() prev_event_context in any way.
thanks for any insight.
thanks also to mathog for your reply.
-- View this message in context: http://inkscape.13.x6.nabble.com/question-about-memory-leaks-tp4966734p49667... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (3)
-
insaner -
Martin Owens -
mathog