GNOME Bugzilla – Bug 671538
memory and gdi leaks on windows xp
Last modified: 2014-03-16 13:04:10 UTC
There is a resource leak under Windows XP related to every draw operation. Just let, for example, a text entry with a cursor pulsing; windows task manager will show increasing memory and gdi usage. On my system the program crash when it has 10000 gdi object: ========= ...... (gtk-demo.exe:2064): Gdk-WARNING **: gdkgc-win32.c:830: SaveDC failed: Memoria insufficiente per eseguire il comando. (gtk-demo.exe:2064): Gdk-WARNING **: gdkgc-win32.c:970: RestoreDC failed: Parametro non corretto. (gtk-demo.exe:2064): Gdk-WARNING **: gdkpixmap-win32.c:279: CreateDIBSection failed: Parametro non corretto. ** Gdk:ERROR:gdkdrawable-win32.c:2040:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ========= This bug is reproducible with gtk-demo.exe ( I'm using gtk+-bundle_2.24.10-20120208 ), both with default theme and with MS-Window theme. Lowering the windows frees memory but not gdi objects. I tested on Windows XP, instead on Windows 7 this bug seems not present.
Created attachment 212373 [details] Testcase for GTK+-2.24.10 memory leak on Windows 2000
The memory leak can easily be observed on Windows 2000 with the attachment gtk_memleak_Win2K.c (GTK+ all-in-one bundle 2.24.10). The leak is steadily growing while the program is running.
Found someone being hit by this bug: http://stackoverflow.com/questions/10344662/gdi-object-leak-on-refocus-in-cairo-or-gtk-on-windows
Also happens in windows 2003 server x64, tested with libs from: gtk+-bundle_2.24.10-20120208_win32.zip I get the same error: ** Gdk:ERROR:gdkdrawable-win32.c:2040:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0) also i can confirm that the crash happens when GDI objects gets 10000, checked with process explorer.
Possible duplicate of bug 685959, but here we also have GDI objects leaks.
I can confirm this error happing on Windows XP (xcare.exe:3804): Gdk-WARNING **: gdkpixmap-win32.c:301: CreateDIBSection failed: Handlingen er gennemført. ** Gdk:ERROR:gdkdrawable-win32.c:2040:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
I am trying to reproduce the assertion failed: (impl->hdc_count == 0) bug. Dieter, your test case seems valid to me and clearly leaks on my XP. I don't hit the assert though. Someone has an idea how to reproduce the assert? Btw, (I haven't looked at the code yet), but why do you think there is a direct relation between the assert and this leak?
I have only observed a steady memory leak (linearly rising RAM usage as seen in the task manager), I do not remember anything about an assertion failed message. The reason for the OS terminating my process was always complete RAM exhaustion after some time.
I can reproduce the gdi leak when the display is 16bpp.
I was embarrassed when I could only reproduce a very tiny leak (because I had since set the display depth to 32bpp), but a display depth of 16 bit makes the leak HUGE, the process is terminated after ~40 seconds (512MB, 850MHz Pentium III, Win2k). Gdk-WARNING **: gdkpixmap-win32.c:279: CreateDIBSection failed: The operation completed successfully. Gdk:ERROR:gdkdrawable-win32.c:2040:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count==0) abnormal program termination Process returned 3 (0x3)
Somehow this reminds me on bug 665507 - maybe I have seen similar messages while developing the solution. Bug 665507 has a patch, which I would apply before checking this one in more detail.
My test case does not use cairo at all (see attachment above), yet the leak is obvious at 16bpp.
Hans, I just tried your patch from bug 665507, unfortunately that doesn't solve the leak
It looks like hbitmap = CreateDIBSection() is not released, sending a patch.
Created attachment 240982 [details] [review] win32: free allocated gdi objects in 16bpp In 16bpp, Gdk is creating hbitmap with CreateDIBSection() and a hdc with CreateCompatibleDC(). Those 2 objects need to be released when the pixmap is finalized.
I am using cairo from git for testing. After this patch is applied, Dieter test doesn't leak big time anymore at 16bpp (and probably not anymore, just a few kb increase after several minutes)
Review of attachment 240982 [details] [review]: This should probably get a review by somebody who knows the win32 backend, but it looks right to me.
(In reply to comment #7) > I am trying to reproduce the assertion failed: (impl->hdc_count == 0) bug. > > Dieter, your test case seems valid to me and clearly leaks on my XP. I don't > hit the assert though. Someone has an idea how to reproduce the assert? > > Btw, (I haven't looked at the code yet), but why do you think there is a direct > relation between the assert and this leak? That assert can very easily be triggered, see bug 699236. For your case, whenever the GDI handles reach 10000, CreateDIBSection() fails, and that failure triggers the impl->hdc_count assert due to the error described in the bug. In that bugreport I made CreateDIBSection() fail in some other way (width -1), but the effect would be the same. I'll see if Marc-Andre's patch actually fixes my issue from bug 699920.
Review of attachment 240982 [details] [review]: ::: gdk/win32/gdkpixmap-win32.c @@ +271,3 @@ + pixmap_impl->is_allocated = TRUE; + I would set is_allocated=TRUE just after SelectObject() at the end of the 16bpp specific section, which is just before setting ->hdc; otherwise, if there is any error in between (e.g. CreateDIBSection fails) we would be calling g_object_unref(pixmap) with is_allocated=TRUE and ->hdc=NULL.
*** Bug 699920 has been marked as a duplicate of this bug. ***
Marc-Andre's fix solves the issue for me (bug 699920).
When will the fix be applied to release packages? 2.24.22 still does not contain this fix.
*** Bug 669701 has been marked as a duplicate of this bug. ***
This bug hit our virt-viewer experience quite hard. It needs only a few minutes for the application to crash. Sadly there are no real alternatives for a Windows user to connect to a SPICE VM console. More at: https://bugzilla.redhat.com/show_bug.cgi?id=1000738 For a non-developer building GTK for Windows is nearly impossible. Is there any chance to get this bug fixed in the next GTK+ 2 build? Thanks in advance.
NB: I supppose you are talking about the remote-viewer windows builds available from spice-space.org or http://virt-manager.org/download/ If yes, these binaries are built using the fedora mingw package, which are not provided by gtk+ maintainers/the gnome project.
You are right. Nevertheless I assume that those packages are built based on the GTK+ source from this project. So the error should be fixed here.
(In reply to comment #19) > I would set is_allocated=TRUE just after SelectObject() at the end of the 16bpp > specific section, which is just before setting ->hdc; otherwise, if there is > any error in between (e.g. CreateDIBSection fails) we would be calling > g_object_unref(pixmap) with is_allocated=TRUE and ->hdc=NULL. Done it that way and pushed to gtk-2-24: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=95985a2181b49a92ec7b8f0eed0dd26052444d86 BTW: the leak can be reproduced with win7 16bpp rdp, too.