[wasm] Safari Maximum call stack size exceeded #15981
Comments
|
@jfizz How did you create the worker.js file? The actual error seems to be coming from |
|
Humm, wondering if this is coming from converting the memoryStream byte array to a string within the WordprocessingDocument. |
|
The worker.js file was created by concatenating my custom code (at the top), with The source for the line in question can be found here https://github.com/OfficeDev/Open-XML-SDK/blob/master/src/DocumentFormat.OpenXml/Packaging/WordprocessingDocument.cs#L306. |
|
I have been able to recreate the project here locally from master but not the error. Can you make sure the project is outputting the correct files. Using these packages: Both release and debug versions seem to be running correctly. |
|
Using the latest SDK did the trick. Thanks for the help! |
|
Great to hear!! |
|
Unfortunately, I spoke too soon. The latest sdk fixes the issue for the sample I have uploaded the failing doc as |
|
I ended up opening a bug for this one: https://bugs.webkit.org/show_bug.cgi?id=200918 Hopefully they can provide a little assistance. |
|
I also checked this on mobile safari and it works correctly. Added that to the comments in the bug opened. |
|
Just to note that there will be surely a regression with Safari 13 / iOS 13, if Apple doesn't fix their Safari memory problems on their release the 2019/09/19. I tested with:
With this configuration, Blazor doesn't start at all. Workarounded by adding: <script>var Module;</script>before the blazor.webassembly.js script tag. Then we fall in: Unfortunatly, the only way i have found at the moment is to modify blazor.webassembly.js file, and add somehow a setTimeout mecanism on line 1707. blazor.webassembly.ios13.fix.zip Here my current workaround. With this fix the Blazor startup process will loose 2 seconds at boot time. Except that, i didn't have fallen in new regression about Network call and Tasking at boot time, at least on my iPad it works. I mean, i tested also with a Task.Delay of 5 seconds and without this, and my app was working on both case. Will test on iPhone 6s tomorrow. This is post is just informational. In my opinion, this is mainly a Safari defect. EDIT: Tested on iOS 13 on a iPhone 6s and my fix doesn't work with the 1sec timeout but does work with a 2sec timeout. |
|
@Daddoon Hello Daddoon This regression is a little different and involves booting emscripten from a worker. All communications with mono wasm is then handed off to the worker. This is also not using Blazor but using the WebAssembly bindings. Although, your are right about the other regressions. There has been a PR submitted to rectify the |
|
Have the same issue with I've built the code with debug info, and managed to get a stack trace: The implementation of such function is here: https://github.com/FFmpeg/FFmpeg/blob/7da57875b57012478aed546818b2d52985d13793/libavcodec/motion_est_template.c#L976 Also, on building I receive the following warning: so it might be related with very big function (because of extensive inlining) I wonder if this makes us one step closer to a clue to the problem |
|
Solved for ffmpeg.js by removing a couple of inline attributes. Now, it reports only but Safari 13 works fine. This is good evidence that huge functions might cause the problem |
…bytes per call, as well as the size of the function that recurses. Fixes iOS13 stack problem. Like mono#17264 but this time under ifdef wasm, to avoid regressing non-wasm benchmarks. And, ideally but not yet, use inline functions and/or macros to share the copied code. Again the recurse/norecurse split. Reopened because of the observed objdump of wasm, far more locals than native code, looks like this will save well over 100 bytes (assuming all locals are nonvolatile and spilled to some stack, without overlap). This fixes iOS13 out of stack problem, on a small repro and on Blazor. So, let's note some more details about wasm and non-wasm. In non-wasm, when a local doesn't fit in registers, or isn't needed for a range of code, but needs to be preserved, it goes to stack. However, stack locations can be reused, for multiple locals, multiple types, given traditional compiler lifetime analysis, often obvious via scopes. CPU can write one type, read another. Or if lifetimes are disjoint, write one type, then write another. It doesn't take code to change the type/identity of variables on the stack. However, in wasm, locals have types. Perhaps part of being safe. Or to aid enregistration by JIT? "reinterpret" is an actual instruction. I gather therefore, that stack packing is much less aggressive in wasm -- integers and floats will remain distinct. That is why this sort of change is more effective for wasm than for non-wasm. Guessing. See mono#17254 (comment). Thanks to @kjpou1 for relentlessly pursuing and providing a repro and hand holding through wasm build/test cycle. Non-wasm (micro?)benchmarks will suffer some. Other than number of locals, could be large recursive functions give grief. Could also be the many temporaries implied by stack machine, again, with a large recursive function. Guessing. Fixes mono#15981. Should fix mono#15989. Should fix mono#16144. Should fix mono#16172. Should fix mono#16986. Should fix chanan/BlazorStrap#226. Should fix dotnet/aspnetcore#15360. Two examples tested, not all of the above. Updated form of mono#16786. Sort of, but not exactly, alternative to mono#16461. They are not conflicting in what they do, but solve same problem -- use less stack.
…bytes per call, as well as the size of the function that recurses. Fixes iOS13 stack problem. Like mono#17264 but this time under ifdef wasm, to avoid regressing non-wasm benchmarks. And, ideally but not yet, use inline functions and/or macros to share the copied code. Again the recurse/norecurse split. Reopened because of the observed objdump of wasm, far more locals than native code, looks like this will save well over 100 bytes (assuming all locals are nonvolatile and spilled to some stack, without overlap). This fixes iOS13 out of stack problem, on a small repro and on Blazor. So, let's note some more details about wasm and non-wasm. In non-wasm, when a local doesn't fit in registers, or isn't needed for a range of code, but needs to be preserved, it goes to stack. However, stack locations can be reused, for multiple locals, multiple types, given traditional compiler lifetime analysis, often obvious via scopes. CPU can write one type, read another. Or if lifetimes are disjoint, write one type, then write another. It doesn't take code to change the type/identity of variables on the stack. However, in wasm, locals have types. Perhaps part of being safe. Or to aid enregistration by JIT? "reinterpret" is an actual instruction. I gather therefore, that stack packing is much less aggressive in wasm -- integers and floats will remain distinct. That is why this sort of change is more effective for wasm than for non-wasm. Guessing. See mono#17254 (comment). Thanks to @kjpou1 for relentlessly pursuing and providing a repro and hand holding through wasm build/test cycle. Non-wasm (micro?)benchmarks will suffer some. Other than number of locals, could be large recursive functions give grief. Could also be the many temporaries implied by stack machine, again, with a large recursive function. Guessing. Fixes mono#15981. Should fix mono#15989. Should fix mono#16144. Should fix mono#16172. Should fix mono#16986. Should fix chanan/BlazorStrap#226. Should fix dotnet/aspnetcore#15360. Two examples tested, not all of the above. Updated form of mono#16786. Sort of, but not exactly, alternative to mono#16461. They are not conflicting in what they do, but solve same problem -- use less stack.
…bytes per call, as well as the size of the function that recurses. Fixes iOS13 stack problem. Like mono#17264 but this time under ifdef wasm, to avoid regressing non-wasm benchmarks. And, ideally but not yet, use inline functions and/or macros to share the copied code. Again the recurse/norecurse split. Reopened because of the observed objdump of wasm, far more locals than native code, looks like this will save well over 100 bytes (assuming all locals are nonvolatile and spilled to some stack, without overlap). This fixes iOS13 out of stack problem, on a small repro and on Blazor. So, let's note some more details about wasm and non-wasm. In non-wasm, when a local doesn't fit in registers, or isn't needed for a range of code, but needs to be preserved, it goes to stack. However, stack locations can be reused, for multiple locals, multiple types, given traditional compiler lifetime analysis, often obvious via scopes. CPU can write one type, read another. Or if lifetimes are disjoint, write one type, then write another. It doesn't take code to change the type/identity of variables on the stack. However, in wasm, locals have types. Perhaps part of being safe. Or to aid enregistration by JIT? "reinterpret" is an actual instruction. I gather therefore, that stack packing is much less aggressive in wasm -- integers and floats will remain distinct. That is why this sort of change is more effective for wasm than for non-wasm. Guessing. See mono#17254 (comment). Thanks to @kjpou1 for relentlessly pursuing and providing a repro and hand holding through wasm build/test cycle. Non-wasm (micro?)benchmarks will suffer some. Other than number of locals, could be large recursive functions give grief. Could also be the many temporaries implied by stack machine, again, with a large recursive function. Guessing. Fixes mono#15981. Should fix mono#15989. Should fix mono#16144. Should fix mono#16172. Should fix mono#16986. Should fix chanan/BlazorStrap#226. Should fix dotnet/aspnetcore#15360. Two examples tested, not all of the above. Updated form of mono#16786. Sort of, but not exactly, alternative to mono#16461. They are not conflicting in what they do, but solve same problem -- use less stack.
…bytes per call, as well as the size of the function that recurses. Fixes iOS13 stack problem. Like mono#17264 but this time under ifdef wasm, to avoid regressing non-wasm benchmarks. And, ideally but not yet, use inline functions and/or macros to share the copied code. Again the recurse/norecurse split. Reopened because of the observed objdump of wasm, far more locals than native code, looks like this will save well over 100 bytes (assuming all locals are nonvolatile and spilled to some stack, without overlap). This fixes iOS13 out of stack problem, on a small repro and on Blazor. So, let's note some more details about wasm and non-wasm. In non-wasm, when a local doesn't fit in registers, or isn't needed for a range of code, but needs to be preserved, it goes to stack. However, stack locations can be reused, for multiple locals, multiple types, given traditional compiler lifetime analysis, often obvious via scopes. CPU can write one type, read another. Or if lifetimes are disjoint, write one type, then write another. It doesn't take code to change the type/identity of variables on the stack. However, in wasm, locals have types. Perhaps part of being safe. Or to aid enregistration by JIT? "reinterpret" is an actual instruction. I gather therefore, that stack packing is much less aggressive in wasm -- integers and floats will remain distinct. That is why this sort of change is more effective for wasm than for non-wasm. Guessing. See mono#17254 (comment). Thanks to @kjpou1 for relentlessly pursuing and providing a repro and hand holding through wasm build/test cycle. Non-wasm (micro?)benchmarks will suffer some. Other than number of locals, could be large recursive functions give grief. Could also be the many temporaries implied by stack machine, again, with a large recursive function. Guessing. Fixes mono#15981. Should fix mono#15989. Should fix mono#16144. Should fix mono#16172. Should fix mono#16986. Should fix chanan/BlazorStrap#226. Should fix dotnet/aspnetcore#15360. Two examples tested, not all of the above. Updated form of mono#16786. Sort of, but not exactly, alternative to mono#16461. They are not conflicting in what they do, but solve same problem -- use less stack.
…bytes per call, as well as the size of the function that recurses. Fixes iOS13 stack problem. Like mono#17264 but this time under ifdef wasm, to avoid regressing non-wasm benchmarks. And, ideally but not yet, use inline functions and/or macros to share the copied code. Again the recurse/norecurse split. Reopened because of the observed objdump of wasm, far more locals than native code, looks like this will save well over 100 bytes (assuming all locals are nonvolatile and spilled to some stack, without overlap). This fixes iOS13 out of stack problem, on a small repro and on Blazor. So, let's note some more details about wasm and non-wasm. In non-wasm, when a local doesn't fit in registers, or isn't needed for a range of code, but needs to be preserved, it goes to stack. However, stack locations can be reused, for multiple locals, multiple types, given traditional compiler lifetime analysis, often obvious via scopes. CPU can write one type, read another. Or if lifetimes are disjoint, write one type, then write another. It doesn't take code to change the type/identity of variables on the stack. However, in wasm, locals have types. Perhaps part of being safe. Or to aid enregistration by JIT? "reinterpret" is an actual instruction. I gather therefore, that stack packing is much less aggressive in wasm -- integers and floats will remain distinct. That is why this sort of change is more effective for wasm than for non-wasm. Guessing. See mono#17254 (comment). Thanks to @kjpou1 for relentlessly pursuing and providing a repro and hand holding through wasm build/test cycle. Non-wasm (micro?)benchmarks will suffer some. Other than number of locals, could be large recursive functions give grief. Could also be the many temporaries implied by stack machine, again, with a large recursive function. Guessing. Fixes mono#15981. Should fix mono#15989. Should fix mono#16144. Should fix mono#16172. Should fix mono#16986. Should fix chanan/BlazorStrap#226. Should fix dotnet/aspnetcore#15360. Two examples tested, not all of the above. Updated form of mono#16786. Sort of, but not exactly, alternative to mono#16461. They are not conflicting in what they do, but solve same problem -- use less stack.
|
Should be fixed now |
Here is a demo https://github.com/jfizz/mono-wasm-safari-issue.
python server.pydoc.docx(included in the repo)Maximum call stack size exceededA few things to note:
debugger;statement in_mono_wasm_invoke_methodresolved the issue (with the devtools open and breakpoints enabled)Originally posted by @jfizz in #8374 (comment)
The text was updated successfully, but these errors were encountered: