Replies: 3 comments 1 reply
-
Be helpful to know which version intorduced the change, then you can look at the git log to see if any
If you can easily reproduce the problem then debugging the render process is fairly trivial. Build the project from source and add the I don't recally any similar reports and without an example to reproduce the problem it's unclear what's going on in this case. |
Beta Was this translation helpful? Give feedback.
-
That is my current to-do list. Going to make a couple different builds to figure out exactly when it started acting up and see if it was just a fluke with 114
Thanks, I didn't know about that flag. Been hacking a similar behavior with a hard coded breakpoint. This will be much quicker. |
Beta Was this translation helpful? Give feedback.
-
For what it is worth, this is an issue with the old synchronous javascript stuff. Still not sure of the exact reason or how but basically if there were multiple calls to c# objects they would slightly overlap with the destruction of the object. The effect was calls were being made on a browser that didn't exist anymore but the handle still did. The binding would think it could still run and boom. |
Beta Was this translation helpful? Give feedback.
-
Curious if @amaitland anyone has seen this or any if anyone has any idea what could cause it.
So we have been getting a lot of reports of pages becoming blank white while browsing. After a quick look it was what I would assume, the renderer process is crashing. So after doing some dump analysis I found the issue is in CefSharp\CefSharp.BrowserSubprocess.Core\BindObjectAsyncHandler.h. On line 161 this code is throwing a null exception because rootObjectWrappers is null.
if (!rootObjectWrappers->TryGetValue(frame->GetIdentifier(), rootObject))
After a some poking around I found the CefBrowserWrapper object had in fact been destructed. Well the destructor had been called. The object still appeared to be valid and wasn't nulled out in the BindObjectAsyncHandler. Which I wouldn't think would be possible or I'm giving the garbage collector & ref counter more credit than they deserve. But my understanding of gcroot is tenuous at best.
I can prevent the crash by adding the following check
after the existing
I am hoping to figure out how we are getting into the state though, since it leaves the browser in an odd state and further calls to ExecuteJavaScriptAsync just throw the exception I added. Any advice or guidance would be greatly appreciated.
Some details:
This started when we jumped from CEF 111 to CEF 114.
I haven't been able to reproduce a simpler version of the issue with the test apps (CEF & CefSharp.Winform), so there isn't really code to share.
I can reproduce the issue fairly easily with our browser. Sadly it's by doing a search on Google and selecting image results.
Beta Was this translation helpful? Give feedback.
All reactions