Sporadic JCEF Crashes with fatal "small_bitmap != nullptr"
Posted: Wed Jul 31, 2019 3:29 am
One of our clients has a problem on one of his client machines that our product crashes sporadically (about once a day) when viewing a PDF with JCEF.
The use case is the following:
It's some kind of document browser, on the left side, there's a table with the documents available (AWT).
If the selected document is a PDF (or HTML) a browser (cefbrowser+cefclient) is initialized and the PDF is loaded. The browsers UI will be shown on the right side.
When another document is selected (non PDF or HTML) the browser is closed.
The crash seems to happen while rendering the PDF into the native Windows GDI bitmap objects.
Restarting the program and retrying the use case again works, so it might be a leak or something.
The environment:
JCEF version 3325 (32 bit), Windows 10 64 bit, Java version: oracleJDK 8u172.
Crash details:
A logfile with verbose logging is attached.
Current analysis status:
The crash itself seems to happen because of following check in gdi_debug_util_win.cc:
CHECK(small_bitmap != nullptr);
The method executing this is called "CollectGDIUsageAndDie", so I guess the caller already had a similar problem and wanted to write some debug info somewhere and expects the CHECK to fail.
I don't think the problem is an exhaustion of GDI Objects in the java process because the same method checks if the allocated GDI Objects are less than 9990 and the process limit of objects is 10000.
My next steps are:
- check the GDI Objects count used by our Java process to ensure that the GDI Object Count is not the problem.
- check the value of the max GDI Objects available for the process in the registry.
- Getting more detailed informations: I'll try to convince our customer to accept the 1,65 GB libcef.dll.pdb file to get a more detailed crash info
I suspect that the problem happens because of something on the specific clients environment because no other client machine on any customer has this behavior.
Does anybody of you know of this problem or what might cause or fix it?
The use case is the following:
It's some kind of document browser, on the left side, there's a table with the documents available (AWT).
If the selected document is a PDF (or HTML) a browser (cefbrowser+cefclient) is initialized and the PDF is loaded. The browsers UI will be shown on the right side.
When another document is selected (non PDF or HTML) the browser is closed.
The crash seems to happen while rendering the PDF into the native Windows GDI bitmap objects.
Restarting the program and retrying the use case again works, so it might be a leak or something.
The environment:
JCEF version 3325 (32 bit), Windows 10 64 bit, Java version: oracleJDK 8u172.
Crash details:
- Code: Select all
[2912:10092:0730/133012.683:FATAL:gdi_debug_util_win.cc(133)] Check failed: small_bitmap != nullptr.
Error initializing symbols (8). Dumping unresolved backtrace:
642CE5F0
642A8BED
6425F400
661287F8
6469077C
646900F9
6468FFB6
64FC6672
64FE79BA
64FECE47
64FCB5F4
64FC7C10
64FC6DCF
664B6D2D
642CB8D9
642E6723
642936B6
642939F7
64293B0E
642E7B3D
642E77CE
6429340F
6425E1CE
642A20AB
642A2227
6429293B
760C0419
77DD662D
77DD65FD
A logfile with verbose logging is attached.
Current analysis status:
The crash itself seems to happen because of following check in gdi_debug_util_win.cc:
CHECK(small_bitmap != nullptr);
The method executing this is called "CollectGDIUsageAndDie", so I guess the caller already had a similar problem and wanted to write some debug info somewhere and expects the CHECK to fail.
I don't think the problem is an exhaustion of GDI Objects in the java process because the same method checks if the allocated GDI Objects are less than 9990 and the process limit of objects is 10000.
My next steps are:
- check the GDI Objects count used by our Java process to ensure that the GDI Object Count is not the problem.
- check the value of the max GDI Objects available for the process in the registry.
- Getting more detailed informations: I'll try to convince our customer to accept the 1,65 GB libcef.dll.pdb file to get a more detailed crash info
I suspect that the problem happens because of something on the specific clients environment because no other client machine on any customer has this behavior.
Does anybody of you know of this problem or what might cause or fix it?