window.onerror（）中的WebAssembly崩溃信息
我正在尝试为我的WebAssembly应用程序收集崩溃日志。它是由Emscripten构建的，所有内容都是从同一领域提供的，并在Chrome中进行了测试。在开发人员控制台中，当发生崩溃时，我会看到一个有堆栈跟踪的正确错误，我想捕获它并将其发送到服务器。
相反，我只会收到“脚本错误”。传递到window.onerror（），第五参数为null。 这应该在违反同一 - 原始政策时发生（链接的问题仅与JavaScript有关，不谈论此WebAssembly特定问题。）.js文件中发生的错误没有此问题，只有WebAssembly运行时错误。
我将Crossorigin属性添加到Emscripten生成的.js文件中。该站点在安全上下文中运行，响应对象传递到webAssembly.instantiatestreaming（）（在emscripten生成的.js文件中）具有“基本”为.Type，因此据我了解，它已经知道它已经具有对此可以做什么没有限制。 “ access-control-allow-origin”标头设置为“*”。
由于某种奇怪的原因，我设法完全使用堆栈跟踪获得了一次完全错误，因此显然是可能的，但似乎以相同的方式做所有的事情，我无法让它再次工作。
如何解决？
I am trying to collect crash logs for my WebAssembly application. It's built with emscripten, everything is served from the same domain, testing in Chrome. In the developer console I see a proper error with stack trace when a crash occurs, I'd like to capture this and send it to a server.
Instead I am only getting "Script error." passed to window.onerror() and the fifth parameter is null. This is supposed to happen when violating the same-origin policy (linked question is only about javascript, does not talk about this WebAssembly-specific problem.) Errors occurring in the .js file don't have this problem, only webassembly runtime errors.
I added the crossorigin attribute to the .js file generated by emscripten. The site is running in secure context, the Response object passed to WebAssembly.instantiateStreaming() (in the emscripten-generated .js file) has "basic" as its .type, so as I understand it has no restrictions on what can be done with it. "Access-Control-Allow-Origin" header is set to "*".
For some weird reason I managed to get the full error with stack trace exactly once, so it is apparently possible, but seemingly doing everything the same way I can't get it to work again.
How can this be solved?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
instantiateStreaming是可以基于的，因此可以尝试window.addeventlistener（'UnhandledReptivection'）？instantiateStreamingis promised based so maybe trywindow.addEventListener('unhandledrejection')?