Crash while using FolderSchemeHandlerFactory

[argon500]

What version of the product are you using?
v4.0.30319
What version are you using? Nuget? CI Nuget? build from a branch? If so which branch? e.g. 53.0.1
57.0.0.0
What architecture x86 or x64?
x64
On what operating system?
Win10
Are you using WinForms, WPF or OffScreen?
WinForms -- Using Visual Studio 2017 CE

What steps will reproduce the problem?

1. Download cesiumjs (http://cesiumjs.org/downloads.html)
2. Unzip this to a local folder
3. Create new winform and code as posted on https://pastebin.com/zNQEcTDz Please provide detailed information here, enough for someone else to reprodce your problem.Please no binary (zip, etc) links, fork the MinimalExample and push your changes to GitHub. (Alternatively use a code sharing service list Gist or Pastebin).
   See https://pastebin.com/zNQEcTDz
   After clicking menu option for mBrowser.Load("local://entime/index.html"); wait for page to load then click "Sandcastle"

What is the expected output? What do you see instead?

Expect similar output to http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html

Please provide any additional information below.

A stack trace if available, any Exception information.

Faulting application name: Entime.exe, version: 1.0.0.0, time stamp: 0x590e0466
Faulting module name: libcef.dll, version: 3.2987.1601.0, time stamp: 0x58e72de2
Exception code: 0xc000041d
Fault offset: 0x0000000001c0e3b1
Faulting process id: 0x1ed4
Faulting application start time: 0x01d2c68c2ff90174
Faulting application path: C:\Projects\Entime\Entime\bin\x64\Debug\Entime.exe
Faulting module path: C:\Projects\Entime\Entime\bin\x64\Debug\libcef.dll
Report Id: 7574d2d2-28f5-4a80-8a0b-5b7f1075c5ab
Faulting package full name: 
Faulting package-relative application ID: 

Does the cef log provide any relevant information? (By default there should be a debug.log file in your bin directory)

[0505/183326.887:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain
[0505/183659.619:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain
[0505/191024.542:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain
[0505/191441.586:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain
[0505/195302.685:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain
[0505/213244.015:ERROR:child_thread_impl.cc(762)] Request for unknown Channel-associated interface: ui::mojom::GpuMain

Any other background information that's relevant? Are you doing something out of the ordinary? 3rd party controls?

This is all vanilla visual studio and nuget version of cefsharp. No additional controls or code

Does this problem also occur in the CEF Sample Application from http://opensource.spotify.com/cefbuilds/index.html?
This will only occur if a FolderSchemeHandlerFactory is used as far as I can tell
To compare with WPF run cefclient --multi-threaded-message-loop --off-screen-rendering-enabled
Not using WPF
To compare with WinForms run cefclient --multi-threaded-message-loop

If you can reproduce the problem with cefclient then you'll need to report the bug on https://bitbucket.org/chromiumembedded/cef/overview there is no point opening an issue here. (Make sure you search before opening an issue)Please include the version you tested with e.g. cef_binary_3.3029.1611.g44e39a8_windows64_client.tar.bz2

When I load the same from a web server on localhost (no scheme same files) there is no problem.

I can load a stock page via FolderSchemeHandlerFactory containing the cesium map viewer with no problem...this seems to be triggered from something in the cesium sandcastle.

[amaitland]

Please use the Bug Report template provided at https://github.com/cefsharp/CefSharp/blob/master/ISSUE_TEMPLATE.md#bug-report

Also please fork the https://github.com/cefsharp/CefSharp.MinimalExample project and provide an example that reproduces your problem.

[amaitland]

Can you fork the Minimumexample and demo your problem? Time is limited and the more work required to investigate the less likely it'll happen.

[argon500]

Hi,  Its done. The only file modified is https://github.com/argon500/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/Program.cs  The javascript application (cesium) is too large to upload to github. It can be downloaded from http://cesiumjs.org/downloads.html   Extract the downloaded zip file to c:\entime\cesium then compile/run the forked minimalexample. The url you want to put in the address bar is local://entime/Apps/Sandcastle/index.html  There is no rush to fix the bug. I am able to proceed with my work. Take Care

[amaitland]

If that's all you've changed then it's likely a bug in CEF, you'll need to get a symbolized stack trace.

https://bitbucket.org/chromiumembedded/cef/wiki/CrashReporting.md
https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting#loading-native-symbols-for-easier-diagnosis

[amaitland]

Under the hood FolderSchemeHandlerFactory uses the native CefStreamResourceHandler implementation

https://github.com/cefsharp/CefSharp/blob/cefsharp/57/CefSharp.Core/SchemeHandlerFactoryWrapper.h#L52

[amaitland]

Also if your new to GitHub, please checkout https://guides.github.com/features/mastering-markdown/

Formatting would go a long way to making your posts readable.

[argon500]

Thanks a ton for all your help Alex. You are very responsive and helpful! I am new to GitHub so all suggestions are welcome. The dumps and logs indicate that this is definitely a problem in the CEF code and not a cefsharp issue. I am able to do everything I need to do with cefsharp despite this rare bug. Your product is outstanding! Thanks for everything!

…

Sent from my iPhone

On May 7, 2017, at 5:40 PM, Alex Maitland ***@***.***> wrote: Also if your new to GitHub, please checkout https://guides.github.com/features/mastering-markdown/ Formatting would go a long way to making your posts readable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[amaitland]

[0508/112332.044:FATAL:cef_stream_resource_handler.cc(93)] Check failed: stream_.get().

Seems like CefStreamReader::CreateForFile returns NULL unexpectedly, not exactly sure why. Easy enough to add some checks to avoid the hard crash.

You can debug this for yourself if interested https://github.com/cefsharp/CefSharp/blob/cefsharp/57/CefSharp.Core/SchemeHandlerFactoryWrapper.h#L52

[argon500]

Thanks! I'll try it out tomorrow.

…

Sent from my iPhone

On May 8, 2017, at 5:57 PM, Alex Maitland ***@***.***> wrote: [0508/112332.044:FATAL:cef_stream_resource_handler.cc(93)] Check failed: stream_.get(). Seems like CefStreamReader::CreateForFile returns NULL unexpectedly, not exactly sure why. Easy enough to add some checks to avoid the hard crash. You can debug this for yourself if interested https://github.com/cefsharp/CefSharp/blob/cefsharp/57/CefSharp.Core/SchemeHandlerFactoryWrapper.h#L52 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[merceyz]

Seems like CefStreamReader::CreateForFile returns NULL unexpectedly, not exactly sure why. Easy enough to add some checks to avoid the hard crash.

@amaitland I assume this is because the file is already be in use. (Request shows up while another one is in progress)

CefStreamReader::CreateForFile seems to read from disk every time, which doesn't seem ideal

[amaitland]

I assume this is because the file is already be in use. (Request shows up while another one is in progress)

@merceyz That is quite likely though I'm surprised the file isn't opened for shared read.

https://bitbucket.org/chromiumembedded/cef/src/f035232c082f837d2b85bd7821a93a54fc742775/libcef/browser/stream_impl.cc?at=2987&fileviewer=file-view-default#stream_impl.cc-21
https://cs.chromium.org/chromium/src/base/files/file_util_win.cc?q=base::openfile&l=627

Quick look suggests it's using _wfsopen, so should be possible.

CefStreamReader::CreateForFile seems to read from disk every time, which doesn't seem ideal

I cannot imagine that's much different in performance to using the file:// scheme. As you cannot reuse a CefResourceHandler reading directly from disk vs storing data in memory becomes a debatable question depending on the usage scenario.

[merceyz]

As you cannot reuse a CefResourceHandler reading directly from disk vs storing data in memory becomes a debatable question depending on the usage scenario.

You can however reuse the ResourceHandler.

If you were to read in the data upon calling ResourceHandler.FromFile you'd have full control and could reuse it.
With a few extra lines you could also work around
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=15119

This would effectively revert 6691d00
So if you were to revert that i could apply the changes for you

[amaitland]

You can however reuse the ResourceHandler.

If the data is >32kb then reusing the ResourceHandler would cause the same problem as outlined in your ceforum post?

If you were to read in the data upon calling ResourceHandler.FromFile you'd have full control and could reuse it.

FromFile didn't do anything more than set a property and a flag, it never Read any data directly.

This would effectively revert 6691d00

No thankyou, I think that's a better approach, gives more managed code options and allows for additional types to be added later (the small amount of code duplication could be improved). I'm not quite sure what changes your proposing, you can easily replace CefStreamReader::CreateForFile with
File.OpenRead and pass the FileStream to ResourceHandler.FromStream.

By all means improve FolderSchemeHandlerFactory to work around the problem you've highlighted on ceforum.

[merceyz]

If the data is >32kb then reusing the ResourceHandler would cause the same problem as outlined in your ceforum post?

Yes, there is however a simple workaround by placing the Callbacks from ProcessRequest in a queue and handling one at a time.

I'll create a PR showing my proposals instead of trying to explain it

[amaitland]

Yes, there is however a simple workaround by placing the Callbacks from ProcessRequest in a queue and handling one at a time.

Interesting idea, sounds workable 👍 You can likely update the default RequestHandler implementation.

[amaitland]

Going with the simplest fix for now, see 13c9c9c

By all means make further improvements 👍