`abort()`, apparently due to `mono.js.mem` missing
chucker opened this issue · comments
Thanks for this project!
I've tried dropping it into a Blazor project and then running that in Safari (Release 59 (Safari 12.0, WebKit 13606.1.21)), but while that makes it no longer crash, it does fail. The console says:
[Log] Buggy webkit detected (blazor.polyfill.min.js, line 1)
[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (mono.js.mem, line 0)
[Warning] a problem seems to have happened with Module.memoryInitializerRequest, status: 404, retrying mono.js.mem (mono.js, line 1)
[Error] abort(). Build with -s ASSERTIONS=1 for more info.
abort (mono.js:1:173897)
_abort (mono.js:1:138319)
_monoeg_log_default_handler (Anonymous Script 1 (line 195414))
_monoeg_g_logstr (Anonymous Script 1 (line 218690))
_monoeg_g_logv_nofree (Anonymous Script 1 (line 208543))
_monoeg_g_logv (Anonymous Script 1 (line 226212))
_monoeg_g_log (Anonymous Script 1 (line 218160))
_monoeg_g_calloc (Anonymous Script 1 (line 191176))
_monoeg_malloc0 (Anonymous Script 1 (line 234893))
_monoeg_g_hash_table_new (Anonymous Script 1 (line 198590))
_mono_aot_init (Anonymous Script 1 (line 198421))
_mini_init (Anonymous Script 1 (line 73657))
_mono_jit_init_version (Anonymous Script 1 (line 236047))
_mono_wasm_load_runtime (Anonymous Script 1 (line 192015))
ccall (mono.js:1:5657)
(anonymous function) (mono.js:1:6038)
(anonymous function) (blazor.js:760)
callRuntimeCallbacks (mono.js:1:15864)
postRun (mono.js:1:16904)
doRun (mono.js:1:173110)
run (mono.js:1:173269)
runCaller (mono.js:1:172712)
removeRunDependency (mono.js:1:18358)
finish (mono.js:1:92410)
processData (mono.js:1:92676)
(anonymous function) (mono.js:1:92789)
xhr_onload (blazor.js:772)
It seems I need to ship an additional file, but I'm not sure from where?
Never mind — the problem is apparently that I do have the file; it's probably just that IIS doesn't map .mem to a proper MIME type.
I can't test that right now, unfortunately.
However, the docs should probably point this out!
OK, I've been able to test it now. It works perfectly in Safari once the type is mapped.
Specifically, while Blazor does supply a web.config to map some MIME types, it misses .mem (arguably a bug in Blazor?). Add another mapping in this section:
<configuration>
<system.webServer>
<staticContent>Like so:
<mimeMap fileExtension=".mem" mimeType="application/octet-stream" /> 
Sorry for the late reply, it seem i am not notified since i have moved my projects on my organization!
Reading your post...
Your are right, i think Blazor by default may missing some mimetypes, i also had to do some similar thing in order to get the things working intially.
Also the thing may be a little different, if you use a self-hosted Blazor or a Blazor app with ASP.NET Core as backend.
I'm using the last one (Kestrel), but hosted in IIS . From ASP.NET Core you may have this type of line instead, in your configuration in Startup.cs:
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression(options =>
{
options.EnableForHttps = true;
options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[]
{
MediaTypeNames.Application.Octet,
WasmMediaTypeNames.Application.Wasm,
MimeTypes.GetMimeType("svg")
});
});
}Of course, if you use the legacy ASP.NET or IIS hosting (not Kestrel from IIS), your configuration is also valid, as IIS will allow you to read web.config files.
Btw, i don't think you issue is related to Blazor.Polyfill, so may i close this issue ?
Did you resolve your problem on your side ?
Hi,
feel free to close it — it does work for me now. It's not really a bug on Polyfill's end; I just thought you might want to point it out in the README.
Thanks
Actually, my previous answer is wrong as the code here is for compression on MimeType, not MimeType managing. However, i think that Kestrel behave differentyle about MimeTypes by default, same for IIS Express .
I will point this check on README, thanks for your review!
Thanks for the review @chucker ! Updated README file on your advices.
Also, it's not the subject, but for info if you have not read yet this has been added to the last version of the project:
Fallback to asmjs for buggy WebAssembly in Webkit based browsers, like Chrome and Safari. This include versions 604.1.34 to 605.1.33 of Webkit at the moment.
So if you are using Safari from iOS, you will fallback to asmjs automatically on theses version. At the end, it concern iOS 11.3 and 11.4 (also 11.2 but it's not about the same bug in Webkit). Safari and Chrome cache and theses related Webkit version 2 seconds after loading the page.
As stated on another thread (on the Blazor github ?) it seem that Apple discovered the bug and we can expect that iOS 12 will be bug free about WebAssembly, therefore having a full WASM support. I imagine that performance will skyrocket compared to asmjs.
But IMO, performance are horrible for Chrome on the related buggy versions of Webkit, where asmjs is the only option.
Hi again,
incidentally, a new Safari Technology Preview was released today, and the crash no longer occurs. So WebKit version 606.1.23.1, which will presumably ship in the final version of iOS 12, is no longer affected.
As stated on another thread (on the Blazor github ?) it seem that Apple discovered the bug
Yes — the crash is filed at https://bugs.webkit.org/show_bug.cgi?id=184829.
Cheers
That's great! As my last release was only covering the specifed known buggy versions, it will behave as WebAssembly (meaning normally!) without any modification.
As i have forgotten to remove the "Buggy webkit version" message in the console.log at startup, you should not see it anymore on the Safari Technology Preview if everything is working right, meaning using WebAssembly.
Thanks again for you review !