First I've noticed that the log window has been popping up frequently with recent builds... unfortunately I've been really tied up the past week and a half and have only skimmed the lists (so I'm sorry if this has been discussed), anyway since this stuff started it says:
-----
(inkscape.exe:2720): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_re
al_draw_pixbuf): assertion `width >= 0 && height >= 0' failed
-----
And it seems to happen if I switch to a different program and then when I pull inkscape back up it spits that out.
The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window:
-----
(inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough
storage is available to process this command.
(inkscape.exe:952): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC
failed: Not enough storage is available to process this command.
(inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The pa
rameter is incorrect.
-----
Unfortunately I wasn't able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one?
And on a side note I'll be posting the tracing quick-start in probably an hour or so for review.
On Wed, 10 Nov 2004, Joshua A. Andler wrote:
The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window:
(inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough
storage is available to process this command.
Unfortunately I wasn't able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one?
At first blush it sounds like a complaint about insufficient disk space. Is your available disk space low?
Obviously, even in low-space situations, Inkscape shouldn't spew error messages continually or lock up; it should give you a warning so you can fix the situation. ;-)
Bryce
At first blush it sounds like a complaint about insufficient disk space. Is your available disk space low?
It depends on your standards... I surely hope that 45gigs free isn't considered low these days. Damn spoiled computers... =)
Obviously, even in low-space situations, Inkscape shouldn't spew error messages continually or lock up; it should give you a warning so you
can
fix the situation. ;-)
I gave my comp a restart just in case and continued working and have not had that really bad issue since (however the first issue which I can continue working with continues to happen). But, it was definitely stuck in some kind of loop, because it just kept spewing those three messages repeatedly. I've never witnessed inkscape do anything of the sort before.
-Josh
On Wed, 10 Nov 2004, Joshua A. Andler wrote:
I gave my comp a restart just in case and continued working and have not had that really bad issue since (however the first issue which I can continue working with continues to happen). But, it was definitely stuck in some kind of loop, because it just kept spewing those three messages repeatedly. I've never witnessed inkscape do anything of the sort before.
I think the second issue is the result of a Windows bug then. If the underlying system isn't in a sane state your own code cannot behave in a predictable fashion.
That's why I essentially stopped doing Windows development back in 1997.
(We should still verify that we handle failure of gdk calls in an appropriate fashion.)
-mental
On Wed, 10 Nov 2004, Bryce Harrington wrote:
At first blush it sounds like a complaint about insufficient disk space. Is your available disk space low?
The error usually indicates that Windows is running out of GDI resources or handles (device contexts, fonts, brushes, etc...). I don't think any remaining Inkscape code directly touches the Windows GDI, though.
Assuming it's not a Windows bug or some other application screwing things up, this would indicate either:
* libgdk leaking GDI resources
* inkscape leaking libgdk resources
A remote third possibility might be virtual memory exhaustion, but I would expect other code to fail first in that case, and I wouldn't expect it to happen immediately on startup.
-mental
So Im working in Inkscape and it did the spazzing out again. As usual it's Win32, first build of the day in the Win32-snap dir. I was working on the tutorials and clicked on the "create and edit text objects" button (left toolbar) and that's apparently what triggered it. It behaved almost the same way as last time, except after spewing that stuff out for a minute or so it gave me control of inkscape again. However, it continued to keep spewing that stuff out pretty consistently in the background in the log window. From the log window (this is what it repeated hundreds of times):
----- (inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1234: LineTo failed: The parameter is incorrect.
(inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1261: LineTo failed: The parameter is incorrect.
(inkscape.exe:3892): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command.
(inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command.
(inkscape.exe:3892): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The parameter is incorrect. -----
Also, I found a way to recreate the other issue I am having regularly. In Windows (confirmed both at work & home on XP) if you choose to have the Windows taskbar "autohide", open Inkscape and maximize it. Then just make the taskbar popup. It will spit out:
----- (inkscape.exe:2604): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_real_draw_pixbuf): assertion `width >= 0 && height >= 0' failed
(inkscape.exe:2604): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_real_draw_pixbuf): assertion `width >= 0 && height >= 0' failed ----- It always spits it out in pairs like that too.
I suppose I should file RFEs for these, but won't have time till a little later, but I figured I'd just let you guys know in the meantime.
-Josh
-----Original Message----- From: inkscape-devel-admin@lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Joshua A. Andler Sent: Wednesday, November 10, 2004 10:37 AM To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Recent error messages
First Ive noticed that the log window has been popping up frequently with recent builds... unfortunately Ive been really tied up the past week and a half and have only skimmed the lists (so Im sorry if this has been discussed), anyway since this stuff started it says: ----- (inkscape.exe:2720): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_re al_draw_pixbuf): assertion `width >= 0 && height >= 0' failed ----- And it seems to happen if I switch to a different program and then when I pull inkscape back up it spits that out. The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window: ----- (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The pa rameter is incorrect. ----- Unfortunately I wasnt able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one? And on a side note Ill be posting the tracing quick-start in probably an hour or so for review.
On Mon, 15 Nov 2004, Joshua A. Andler wrote:
Can't really spend time on this until this evening, but I can at least weigh in briefly:
(inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1234: LineTo failed: The parameter is incorrect.
(inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1261: LineTo failed: The parameter is incorrect.
libgdk is trying to use an invalid GDI DC handle.
(inkscape.exe:3892): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command.
(inkscape.exe:3892): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command.
We ran out of memory to save a DC's state, or create a new one (the latter being a potential source of invalid DC handles). There used to be a separate pool for device contexts (maximum 16k of them), but I think that limit has been lifted since Windows NT, so if it's really a memory issue I would expect main memory is being exhausted..
(inkscape.exe:3892): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The parameter is incorrect.
Either an invalid DC handle, or there was no saved state to restore (possibly because of the earlier save failure).
These are all Win32 GDI errors, happening in libgdk code. All I can think of offhand (if it's not a Windows or libgdk bug) is that we're using invalid GDK handles somehow, or we're exhausting memory.
When you're seeing these errors, what do you see as far as memory usage in Task Manager?
Also, I found a way to recreate the other issue I am having regularly. In Windows (confirmed both at work & home on XP) if you choose to have the Windows taskbar "autohide", open Inkscape and maximize it. Then just make the taskbar popup. It will spit out:
(inkscape.exe:2604): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_real_draw_pixbuf): assertion `width >= 0 && height >= 0' failed
(inkscape.exe:2604): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_real_draw_pixbuf): assertion `width >= 0 && height >= 0' failed
It always spits it out in pairs like that too.
This one probably isn't memory-related, and could well be a bug with repainting in one of our custom widgets.
I suppose I should file RFEs for these, but won't have time till a little later, but I figured I'd just let you guys know in the meantime.
Use the Bug tracker rather than the RFE tracker.
It would be helpful (not required) if you could get a backtrace with a gdb for each error (set a breakpoint on g_log), so we can identify which part of Inkscape is calling the portions of libgdk that are reporting these errors.
I'd probably recommend setting up a breakpoint with the following sequence of gdb commands:
break g_log commands finish end
This way, you can see if the error is one of the ones you're interested in; if it is, you can use "bt" to get a backtrace, and/or "continue" to resume execution.
Some folks here should be able to help you out more as far as using gdb on Windows if you've not done it before.
Can anyone else on Windows duplicate either of these sets of symptoms (deliberately using up memory for the former, or following Josh's instructions for the latter)?
-mental
--- MenTaLguY <mental@...3...> wrote:
Can anyone else on Windows duplicate either of these sets of symptoms (deliberately using up memory for the former, or following Josh's instructions for the latter)?
can reproduce the latter no probs, will have a go at eating up all my memory now. :)
Sim
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
--- MenTaLguY <mental@...3...> wrote:
Can anyone else on Windows duplicate either of these sets of symptoms (deliberately using up memory for the former, or following Josh's instructions for the latter)?
cant reproduce the first one, ran some big images through the tracer, loaded several large video files so my system was out of physical memory, and it worked fine (if rather slowly.) Without more precise conditions I cant do much more. Did manage to get IS using in excess off 200Mb of memory tho. If you open a large file (keys and mouse is a good one) then grab everything, and move it round lots, (by keys is good) you can literally watch the memory get gobbled up. (maybe as the undo list builds up?) every move was adding a coulple of meg to the IS memory usage stat. The worrying thing was it didnt seem to free when i shut that doc, only when i shut the app.
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
On Mon, 15 Nov 2004, John Cliff wrote:
Did manage to get IS using in excess off 200Mb of memory tho. If you open a large file (keys and mouse is a good one) then grab everything, and move it round lots, (by keys is good) you can literally watch the memory get gobbled up. (maybe as the undo list builds up?) every move was adding a coulple of meg to the IS memory usage stat.
Probably the undo list, yes. The full before and after text for each attribute change is saved (and due to compensation and style changes, there are several for each object). Multiplied by the number of objects in keys.svg, that's got to be a healthy amount of memory.
It's not as bad as it could be: using the garbage collector I've implemented aggressive sharing of string data within the repr code (which includes undo). In the pre-gc days we used to make separate copies everywhere.
The worrying thing was it didnt seem to free when i shut that doc, only when i shut the app.
There may be another refcount leak, or the garbage collector may simply not have run a collection pass yet--absent an explicit request, it only garbage collects every so many bytes allocated.
From gdb, you should be able to force a garbage collection by suspending
the process and issuing:
call GC_gcollect()
at the gdb prompt.
Be aware though that because of memory fragmentation, even once we fix the issue you won't see a full 100% of the blocks used returned to the OS (although they can be internally reused), at least until the process exits. This is true of all allocators, both standard malloc and the boehm collector's alike.
-mental
Can anyone else on Windows duplicate either of these sets of
symptoms
(deliberately using up memory for the former, or following Josh's instructions for the latter)?
cant reproduce the first one, ran some big images through the tracer, loaded several large video files so my system was out of physical memory, and it worked fine (if rather slowly.) Without more precise conditions I cant do much more.
Ok, when working on the tutorials Inkscape got "uber-funked" ~15 times. It is always when I am working with text objects. All I can recommend is to grab the one of the larger tutorials I uploaded and mess around. Move text boxes, edit some text, etc. Occasionally hop into another program and hop back as well as I always multitask and just want to cover all bases. It has done it in every Win32 build for the past couple weeks, on multiple systems. An interesting thing is that the window that starts spazzing/becomes non-responsive (and makes the log go nuts) doesn't seem to affect other open Inkscape windows (within the same process). And for note this is usually after ~20-30 mins of editing a document.
I don't quite understand the process for gdb, so I haven't been able to pull any good information other than what inkscape's log window says. Due to the frequency of me bringing it down, I have to recommend we try to get it fixed before release. I will file a bug report on it once I can reproduce it on demand. Otherwise, gdb will be the way to track it down, huh?
-Josh
On Thu, 18 Nov 2004, Joshua A. Andler wrote:
I don't quite understand the process for gdb, so I haven't been able to pull any good information other than what inkscape's log window says. Due to the frequency of me bringing it down, I have to recommend we try to get it fixed before release. I will file a bug report on it once I can reproduce it on demand. Otherwise, gdb will be the way to track it down, huh?
Maybe. Knowing the backtrace at the point where each one of the warnings is emitted can help us focus our attention on the right code.
Just as important, though, is establishing step-by-step instructions for reliably reproducing the bug. Without that, we can't really tackle it scientifically.
-mental
Ok, when working on the tutorials Inkscape got "uber-funked" ~15 times. It is always when I am working with text objects.
Is this with flowed text? If so it's likely
https://sourceforge.net/tracker/index.php?func=detail&aid=1057045&gr...
Otherwise, as Mental wrote, we need reproducible steps and a backtrace.
participants (5)
-
Bryce Harrington -
bulia byak -
John Cliff -
Joshua A. Andler -
MenTaLguY