On Sun, Jun 12, 2005 at 07:42:15PM +0200, Christoph Leuzinger wrote:
First off, sorry for thrashing this list with messages, but I have one other addition:
Am 12.06.2005 19:25 schrieb Christoph Leuzinger:
Am 11.06.2005 12:29 schrieb bulia byak:
On 6/11/05, Christoph Leuzinger <chris+ml@...463...> wrote:
Something's definitely wrong here. By switching between two files in inkview I can cause the process to grow to an arbitrary size in memory. It will crash if I switch "fast" from one to the other repeatedly.
It would be helpful if you could test CVS version and compare the memory consumption. There were a few memory-related fixes.
The bug is still there in CVS as of 11062005.
I did some further testing which showed that the process will crash if its size exceeds the limits set with "ulimit -d" (data segment size).
So, a workaround is to set this limit high enough for my presentation. The process will crash sooner or later, though, because it can be caused to reach any set limit.
I don't know if this is problem is a platform specific one, but in any case I hope that this can be fixed!
I remember running into similar issues with my OLS presentation last year. Fortunately it didn't crash during the presentation, but I did notice when practicing that if I went back and forth a lot, the memory would get chewed up and eventually Inkscape would crash.
If this issue is indeed caused by memory over-utilization, one idea might be to hack the inkview code to purge its memory between each slide.
Look in inkview.cpp.
The first thing I would suggest is to add some error messages. I.e., replace all of the things like this:
if(!ss.doc) return 1; /* none of the slides loadable */
with
if (!ss.doc) { fprintf(stderr, "none of the slides are loadable\n"); return 1; }
Also, it appears that return values are not being checked in inkview.cpp. In general, with gtk you can usually ignore return values without too much trouble, since the routines mostly always work. The one notable exception is the situation when memory is low; then sometimes the routines doing allocation may fail. So since that appears to be the situation we're facing here, it may be quite worthwhile to add these checks.
For instance, routines like gtk_button_new_from_stock() return a pointer to a GtkWidget; if you're low on memory I think it might return NULL. However there are no checks for this circumstance in inkview, and it will just merrily stick the NULL widget into a table and carry on until it crashes. ;-)
The next thing to look at is if the document allocations are balanced with deletions. I.e., look in sp_svgview_show_next(). This routine is run when you move forward in the slideshow. It calls sp_document_new() to allocate a document for the current length. If it succeeds, then it creates a view and stores the pointer to the doc in ss->doc. But it doesn't appear to free the previous document - does it get freed automatically? Would it work better if it did? Also, it doesn't give any warning if sp_document_new failed. Note that if this routine has any problems, then sp_svgview_show_prev, sp_svgview_goto_first, and sp_svgview_goto_last probably will have the same problems.
Anyway, the above steps should be pretty straightforward to do, and even if they don't solve the problem you're encountering, they'll definitely give us all a better idea of why inkview is failing. The inkview.cpp code is only about 500 lines, so should be fairly manageable, even if you don't have much experience yet with Inkscape's internals.
Bryce