Sporadic JCEF Crashes with fatal "small_bitmap != nullptr"

Having problems with building or using the JCEF Java binding? Ask your questions here.

Sporadic JCEF Crashes with fatal "small_bitmap != nullptr"

Postby Phylanx » 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:
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?
Attachments
jcef.log
JCEF logfile of crash with verbose level
(27.21 KiB) Downloaded 684 times
Phylanx
Expert
 
Posts: 201
Joined: Thu Aug 11, 2016 8:17 am

Return to JCEF Forum

Who is online

Users browsing this forum: No registered users and 14 guests