Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(588)

Unified Diff: skia/ext/platform_canvas_win.cc

Issue 75027: Fix the failure to fail in PlatformCanvasWin ctor... (Closed) Base URL: svn://chrome-svn/chrome/trunk/src/
Patch Set: '' Created 11 years, 8 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: skia/ext/platform_canvas_win.cc
===================================================================
--- skia/ext/platform_canvas_win.cc (revision 13641)
+++ skia/ext/platform_canvas_win.cc (working copy)
@@ -19,18 +19,22 @@
// lines. This allows us to see in crash dumps the most likely reason for the
// failure. It takes the size of the bitmap we were trying to allocate as its
// arguments so we can check that as well.
-void CrashForBitmapAllocationFailure(int w, int h) {
- // The maximum number of GDI objects per process is 10K. If we're very close
- // to that, it's probably the problem.
- const int kLotsOfGDIObjs = 9990;
- CHECK(GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS) < kLotsOfGDIObjs);
-
+//
+// Note that in a sandboxed renderer this function crashes when trying to
+// call GetProcessMemoryInfo() because it tries to load psapi.dll, which
+// is fine but gives you a very hard to read crash dump.
+__declspec(noinline) void CrashForBitmapAllocationFailure(int w, int h) {
// If the bitmap is ginormous, then we probably can't allocate it.
// We use 64M pixels = 256MB @ 4 bytes per pixel.
const __int64 kGinormousBitmapPxl = 64000000;
CHECK(static_cast<__int64>(w) * static_cast<__int64>(h) <
kGinormousBitmapPxl);
+ // The maximum number of GDI objects per process is 10K. If we're very close
+ // to that, it's probably the problem.
+ const int kLotsOfGDIObjs = 9990;
+ CHECK(GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS) < kLotsOfGDIObjs);
+
// If we're using a crazy amount of virtual address space, then maybe there
// isn't enough for our bitmap.
const __int64 kLotsOfMem = 1500000000; // 1.5GB.
@@ -42,6 +46,14 @@
CHECK(0);
}
+// Crashes the process. This is called when a bitmap allocation fails but
+// unlike its cousin CrashForBitmapAllocationFailure() it tries to detect if
+// the issue was a non-valid shared bitmap handle.
+__declspec(noinline) void CrashIfInvalidSection(HANDLE shared_section) {
+ DWORD handle_info = 0;
+ CHECK(::GetHandleInformation(shared_section, &handle_info) == TRUE);
+}
+
PlatformCanvasWin::PlatformCanvasWin() : SkCanvas() {
}
@@ -58,8 +70,10 @@
HANDLE shared_section)
: SkCanvas() {
bool initialized = initialize(width, height, is_opaque, shared_section);
- if (!initialized)
+ if (!initialized) {
+ CrashIfInvalidSection(shared_section);
CrashForBitmapAllocationFailure(width, height);
+ }
}
PlatformCanvasWin::~PlatformCanvasWin() {
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698