New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDI DC Handles seem to increase persistently on certain pages. #4

Closed
adamjs opened this Issue Apr 22, 2013 · 5 comments

Comments

Projects
None yet
4 participants
@adamjs

adamjs commented Apr 22, 2013

This tool can be used to inspect GDI allocations: http://www.nirsoft.net/utils/gdi_handles.html

@ghost ghost assigned adamjs Apr 22, 2013

@adamjs

This comment has been minimized.

Show comment
Hide comment
@adamjs

adamjs Jun 21, 2013

Bug occurs sporadically with certain pages (primarily CNN Money homepage) and content.

Seems to be related to certain scripts-- if JavaScript is disabled the issue does not occur.

adamjs commented Jun 21, 2013

Bug occurs sporadically with certain pages (primarily CNN Money homepage) and content.

Seems to be related to certain scripts-- if JavaScript is disabled the issue does not occur.

@Perikles

This comment has been minimized.

Show comment
Hide comment
@Perikles

Perikles Jul 24, 2013

Relevant Chromium issue (for future reference):

https://code.google.com/p/chromium/issues/detail?id=134837

Perikles commented Jul 24, 2013

Relevant Chromium issue (for future reference):

https://code.google.com/p/chromium/issues/detail?id=134837

@lukeN86

This comment has been minimized.

Show comment
Hide comment
@lukeN86

lukeN86 Oct 11, 2013

I disagree, the bug occurs regularly when users browse sites with rich graphics or javascripts. Each navigation to a new page can even add something around 20-100 GDI to the main process (ie the app which hosts Awesomium WPF control), so the app can easily crash after the user browsed only 100 pages (the limit of GDI handles is 10000 per process). The only work around is to shut down the app completely and restart it, which is extremely disruptive.

Without a fix, this severely limits the potential of Awesomium because it causes regular unhandled crashes of our application, thus making it unusable for our users.

lukeN86 commented Oct 11, 2013

I disagree, the bug occurs regularly when users browse sites with rich graphics or javascripts. Each navigation to a new page can even add something around 20-100 GDI to the main process (ie the app which hosts Awesomium WPF control), so the app can easily crash after the user browsed only 100 pages (the limit of GDI handles is 10000 per process). The only work around is to shut down the app completely and restart it, which is extremely disruptive.

Without a fix, this severely limits the potential of Awesomium because it causes regular unhandled crashes of our application, thus making it unusable for our users.

@adamjs

This comment has been minimized.

Show comment
Hide comment
@adamjs

adamjs Oct 24, 2013

There was a bug within the code WebKit uses to query dimensions of the user's screen on Windows. Pages that had scripts that made excessive queries of screen parameters triggered a cascade of leaked DC handles.

This issue has been fixed, we will be releasing an updated build very soon.

Remarks

This bug proved very elusive for number of reasons:

* Utilities for finding GDI leaks are outdated/unmaintained and reported bad information
* The issue happened only on certain pages with no clear pattern
* We mostly hunted in code used for drawing which threw us off the trail

We located the leak using a combination of tools:

1. We used AQTime's resource profiler to determine that DC handles were growing without bounds
   and that calls to 'GetDC' from awesomium.dll were the culprit.
2. We hooked into User32.dll and re-routed the call to GetDC to our own function and set a 
   breakpoint on that to get the callstack. We used the following hooking utility:

http://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x86-x64-API-Hooking-Libra

This led us to a single unmatched call to GetDC(0) within WebKit that was executed within the
main browser process whenever a script tries to query the dimensions of the screen. A single
call to ReleaseDC fixed the issue.

adamjs commented Oct 24, 2013

There was a bug within the code WebKit uses to query dimensions of the user's screen on Windows. Pages that had scripts that made excessive queries of screen parameters triggered a cascade of leaked DC handles.

This issue has been fixed, we will be releasing an updated build very soon.

Remarks

This bug proved very elusive for number of reasons:

* Utilities for finding GDI leaks are outdated/unmaintained and reported bad information
* The issue happened only on certain pages with no clear pattern
* We mostly hunted in code used for drawing which threw us off the trail

We located the leak using a combination of tools:

1. We used AQTime's resource profiler to determine that DC handles were growing without bounds
   and that calls to 'GetDC' from awesomium.dll were the culprit.
2. We hooked into User32.dll and re-routed the call to GetDC to our own function and set a 
   breakpoint on that to get the callstack. We used the following hooking utility:

http://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x86-x64-API-Hooking-Libra

This led us to a single unmatched call to GetDC(0) within WebKit that was executed within the
main browser process whenever a script tries to query the dimensions of the screen. A single
call to ReleaseDC fixed the issue.

@adamjs adamjs closed this Oct 24, 2013

@newmang

This comment has been minimized.

Show comment
Hide comment
@newmang

newmang Nov 3, 2013

Trying to determine if this effects me. Are we talking about JavaScript methods to determine the user's screen size? Because I do use a lot of those.

newmang commented Nov 3, 2013

Trying to determine if this effects me. Are we talking about JavaScript methods to determine the user's screen size? Because I do use a lot of those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment