public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Amal Khailtash <akhailtash@yahoo.com>
To: cygwin-xfree@cygwin.com
Subject: Re: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion 1.7.6, Build Date 2010-03-18
Date: Tue, 27 Jul 2010 14:58:00 -0000 [thread overview]
Message-ID: <736149.10880.qm@web88008.mail.re2.yahoo.com> (raw)
Hi Jon,
This was a great news for me for some time now. I gave your patch a try and
everything seems peachy.
The resources stay at a reasonable number (USER<60, GDI<70) and I have not seen
any problem yet.
Thanks for looking into this and it's great that the leak is found. I am sure
people who use Cygwin/X
appreciate a more stable environment.
I hope I see this patch coming into main releases soon.
Thanks a lot,
-- Amal
________________________________
From: Jon TURNEY <jon.turney@dronecode.org.uk>
To: cygwin-xfree@cygwin.com
Cc: akhailtash@yahoo.com
Sent: Thu, July 22, 2010 4:34:01 PM
Subject: Re: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion
1.7.6, Build Date 2010-03-18
On 19/04/2010 18:33, Amal Khailtash wrote:
> Thanks for looking into this. Yes, it seems this problem shows up for some
>applications. gnome-terminal
> seems to behave better. But konsole and my specific TCL-based application
>(modelsim) seem to suffer
> from this.
>
> The problem is even if I quit the troublesome application, resources are not
>released and that tells me
> the leak is somewhere in the core X server and not the application, but somehow
>
>only shows up for those.
This is expected, because as far as Windows is concerned, all the X windows and
the resources they use are owned by the X server.
> Some of the applications that I found that show this leak are:
>
> * modelsim
> * konsole
> * kfontview
> * kate
>
> It seems KDE-based apps are the worst. The problem is not as severe in
>gnome-based applications.
> But I can see that, even in those, not all resources are released either!
I have (finally) tracked down what I think is causing this leak. It seems we
are leaking the Windows icons we create when the X window has an icon hint
attached. It also seems that menu windows for the problematic apps like konsole
have such an icon hint, so we leak at a vast rate whilst working with them.
(There's not much point in making the Windows icon for these transient windows,
as it can't be seen, so perhaps there's another change needed to avoid the
overhead of generating the Windows icon in these cases)
I've uploaded a build with this fix at [1], patch to follow. Perhaps you could
try it out and see if it works for you?
[1] ftp://cygwin.com/pub/cygwinx/XWin.20100722-git-3e2987e614139d51.exe.bz2
> Another not is that even Xming suffers from this same problem. I assume most
>of the source code is
> shared between XWin and Xming.
It depends which version of Xming you are using, something you should have
mentioned.
If you are using the current version of Xming, that is the case.
If you are using the free version of Xming, that's about 3 years old. There
have been a few changes in the source since then :-)
> ----- Original Message ----
> Subject: Re: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion
>1.7.6, Build Date 2010-03-18
>
> On 06/04/2010 20:05, Amal Khailtash wrote:
>> Click on Session menu and while the menu is open, move to Edit, then View,
>>Bookmarks,
>> Settings and Help and click outside to withdraw menu:
>>
>> Image Name User Objects GDI Objects
>> XWin.exe 39 79
>>
>> Click on any menu item and while the menu is open and move cursor to other menu
>>
>>items
>> a number of (20) times:
>>
>> Image Name User Objects GDI Objects
>> XWin.exe 241 483
>>
>> Keep doing this and you will see the allocated objects keeps increasing and
>>increasing and
>> they are never released even if I close my Konsole window!
>
> Thanks for the clear reproduction steps. With these, I can reproduce this
>problem.
>
> According to the GdiUsage tool this seems to be a GDI bitmap handle being
>leaked. Unfortunately GdiUsage seems to have rusted a bit and doesn't produce
>useful backtraces (and may well not be able to backtrace a cygwin executable,
>anyhow) so locating exactly where the leak is coming from is going to be a bit
>tricky...
-- Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
next reply other threads:[~2010-07-27 14:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 14:58 Amal Khailtash [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-04-17 1:41 Amal Khailtash
2010-03-22 18:38 Amal Khailtash
2010-03-29 17:20 ` Jon TURNEY
2010-03-29 17:21 ` Amal Khailtash
2010-04-05 21:30 ` Jon TURNEY
2010-04-06 21:16 ` Amal Khailtash
2010-04-18 21:09 ` Jon TURNEY
2010-04-20 11:21 ` Amal Khailtash
2010-07-22 20:34 ` Jon TURNEY
2010-07-27 15:01 ` Christopher Faylor
2010-07-27 15:26 ` Csaba Raduly
2010-07-27 17:01 ` Kenneth Wolcott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=736149.10880.qm@web88008.mail.re2.yahoo.com \
--to=akhailtash@yahoo.com \
--cc=cygwin-xfree@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).