Application crash related to libcef.dll version 94.4.9

[magreenblatt]

Original report by Steven Snow (Bitbucket: Steven Snow).

---

We have recently introduced CefSharp and CEF 94 into our application. We are now experiencing a crash originating from libcef.dll. This crash was not experienced using CEF 93 or lower

Faulting application name: CefSharp.BrowserSubprocess.exe, version: 94.4.50.0, time stamp: 0x615bb143
Faulting module name: libcef.dll, version: 94.4.9.0, time stamp: 0x61344ed0
Exception code: 0x4000001f
Fault offset: 0x0338d1fc
Faulting process id: 0x855c
Faulting application start time: 0x01d7bc6767e91e4f
Faulting application path: C:\Program Files (x86)\Emerson\DeltaV\CefSharp.BrowserSubprocess.exe
Faulting module path: C:\Program Files (x86)\Emerson\DeltaV\libcef.dll
Report Id: 906da3b0 (bb)-2201-40cf-8b0f-c40b740e46d3
Faulting package full name:
Faulting package-relative application ID:

We were also able to capture the attached CEF log at the time of the crash. (See attached)

The action this centers around is basically clicking a div in a main CefSharp window in order to open “popup“ CefSharp windows. The simplest instance of the crash is to double click a div after it’s popup has already been opened. This action would normally only result in a toggling of focus away from the popup and back to it.

‌

[magreenblatt]

Original comment by Alex Maitland (Bitbucket: a-maitland).

---

Are you using the official Nuget package for CefSharp? Version 94.4.50 uses CEF version 94.4.5+g0fd0d6f+chromium-94.0.4606.71

How are you using 94.4.9 exactly?

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

CEF 94.4.9 is being used because we custom build CEF in order to enable H.264 video, which is proprietary. That happened to be the version at the time when we got around to pulling the CEF 94 branch for that build. This doesn’t involve us actually modifying CEF at all. I can go back and check that this also occurs with the default contnets of the CefSharp 94 nuget package.

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

This is actually not a problem using the default 94.4.5 cef files it turns out. It seems a little odd that this behavior difference exists with 94.4.9, but it’s more on us to try and get 94.4.5 built for proprietary codec support, rather than use our current 94.4.9 CEF build.

[magreenblatt]

Original comment by Alex Maitland (Bitbucket: a-maitland).

---

If you rebuilt CefSharp from source including building cef-binary to create the updated libcef_wrapper then this is likely a bug introduced in https://bitbucket.org/chromiumembedded/cef/pull-requests/393 which was merged after 94.4.5.

‌

[magreenblatt]

The action this centers around is basically clicking a div in a main CefSharp window in order to open “popup“ CefSharp windows. The simplest instance of the crash is to double click a div after it’s popup has already been opened. This action would normally only result in a toggling of focus away from the popup and back to it.

Please share the reproduction case for this. You can test with the CEF sample application. A symbolized stack trace for the crash would also be helpful.

‌

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

It sounds like the details of the crash may still be relevant, so reopening.

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

Alex, that is correct.

Marshall, I’ll try to find a general case that reproduces the issue that isn’t just from our product crashing. As far as a symbolized stack trace, what do we need to do? The output attached was already being gathered with libcef.dll.pdb present.

Also, do you have any guidance on what actions might cause the attached errors to happen? We have an existing CefSharp load testing application that opens up a large number of browser windows very quickly that may be helpful (the tool can also artificially stress CPU availability), though that doesn’t seem to be sufficient to reproduce the issue by itself.

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

I’ve reproduced with verbose logging enabled, in case that helps. Note that both attached logs were taken with libcef.dll.pdb for 94.4.9 present.

[magreenblatt]

This appears to be the failure:

[1011/160432.873:FATAL:font_cache_skia.cc(190)] Check failed: font_platform_data

As far as a symbolized stack trace, what do we need to do? The output attached was already being gathered with libcef.dll.pdb present.

Was that libcef.dll.pdb for the exact matching CEF version and build type (Debug vs Release)? Was it placed next to libcef.dll in the same directory?

Also, do you have any guidance on what actions might cause the attached errors to happen?

I found one report of the error here, but nothing particularly useful. Reproduction steps will be important for debugging further.

‌

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

I’ve now reproduced the crash with a cef build based on commit 0fd0d6f (bb) (pulled using automate_git.py, to hopefully have the appropriate Chromium commit also be used). This was in hopes on getting one of our internal v94 builds to work, but it actually produced a symbolized error log on crash when using the libcef.dll.pdb from our CEf build.

‌

[1013/141751.252:FATAL:values.cc(199)] Check failed: false. Non-finite (i.e. NaN or positive/negative infinity) values cannot be represented in JSON
Backtrace:
base::debug::CollectStackTrace [0x12CED993+19] (C:\code\chromium_git\chromium\src\base\debug\stack_trace_win.cc:303)
base::debug::StackTrace::StackTrace [0x12C52461+17] (C:\code\chromium_git\chromium\src\base\debug\stack_trace.cc:197)
logging::LogMessage::~LogMessage [0x12C68249+153] (C:\code\chromium_git\chromium\src\base\logging.cc:590)
logging::LogMessage::~LogMessage [0x12C68DEB+11] (C:\code\chromium_git\chromium\src\base\logging.cc:583)
logging::CheckError::~CheckError [0x12C45C9F+15] (C:\code\chromium_git\chromium\src\base\check.cc:107)
base::Value::Value [0x12CE0E56+134] (C:\code\chromium_git\chromium\src\base\values.cc:201)
CefDictionaryValueImpl::SetDouble [0x12C132AC+92] (C:\code\chromium_git\chromium\src\cef\libcef\common\values_impl.cc:901)
`anonymous namespace'::dictionary_value_set_double [0x0F9831C1+129] (C:\code\chromium_git\chromium\src\cef\libcef_dll\cpptoc\dictionary_value_cpptoc.cc:576)
CefDictionaryValueCToCpp::SetDouble [0x0F70258C+60] (C:\projects\cef-binary\cef_binary_3.y.z_windows32\libcef_dll\ctocpp\dictionary_value_ctocpp.cc:574)

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

After a bit of testing, this crash actually occurs during execution of onHover callback function for any of these divs . We are sepcifically calling a method in the C#/.NET shell application via a “Bridge“ to retrieve positioning data for opening a tooltip window (though after experimenting, it doesn’t seem to matter what the method is actually doing). The function on the bridge side appears to execute normally. On the browser side, the libcef crash occurs prior to a value being returned from the bridge call. The onHover works fine if the bridge method call is removed. That unfortunately, isn’t great for reproducing in a general case.

‌

If all else fails, I may be creating a dummy application that does something similar in the next week or so.

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

The action being taken by us that turned out to be causing the crash was trying to return a simple struct containing 4 doubles through on of our application bridges during the onHover event. The fix was to return a json string representation instead, and just deserialize that on the browser/client side.

‌

So basically, the fix is to only exchange primitive data types and strings between the browser and .NET shell application, and avoid complex objects.

[magreenblatt]

Original comment by Steven Snow (Bitbucket: Steven Snow).

---

Resolving, as our problem has been mitigated in our own code

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• changed state from "new" to "resolved"

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• changed state from "resolved" to "open"

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• set attachment to "cefdebug_verbose.log"

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• set attachment to "cefdebug_verbose.log"

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• set attachment to "cefdebug_symbols.log"

[magreenblatt]

Original changes by Steven Snow (Bitbucket: Steven Snow).

---

• changed state from "open" to "resolved"