runtime : fatal error: malloc deadlock #41775
Labels
arch-wasm
WebAssembly issues
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
finnbear
changed the title
finnbear
changed the title
finnbear
changed the title
|
Interesting. The 2 stack traces are slightly different, but they both stem from the calling of nested mallocgc. Even more surprising is this: /cc @neelance |
agnivade
changed the title
agnivade
added
arch-wasm
|
In both traces the call to And it seems like this is exactly what happened in the second trace. It first says: It seems like the WebAssebly host decided to forcefully terminate the WebAssembly binary and |
|
@finnbear You gave a 👍 . Does that mean that we can close this issue? |
My thought is that Go should attempt to predict forceful termination (using the browser's However, as this issue absolutely does not effect my use case (WebGL game), because I don't currently have any tasks that need to be done by Go on page exit, I'm fine with it being closed. |
|
I tried to reproduce this on Firefox. With an infinite loop I get this message after a few seconds: |
|
@neelance Thanks!
With this go script: package main
import (
"time"
)
var m = make(map[int]*int)
func main() {
println("Hello from Go")
for {
for k := 0; k < 1000000; k++ { // spend plenty of time in Go (only necessary to get the "a web page is slowing down your browser message, not necessary for problems when closing the tab)
j := k
m[k] = &j // allocate some memory to force a critical, mutex-locked process to occur
}
time.Sleep(time.Millisecond) // return to JS every so often, just so the page is semi responsive
println("loop")
}
}I was able to get this to appear after pressing the "stop it button" but I didn't actually get to see a panic. Stack traceScript terminated by timeout at: runtime.memhash64@http://localhost:8192/test.wasm:wasm-function[853]:0xb9243 runtime.evacuate_fast64@http://localhost:8192/test.wasm:wasm-function[184]:0x226b9 runtime.growWork_fast64@http://localhost:8192/test.wasm:wasm-function[183]:0x21f63 runtime.mapassign_fast64@http://localhost:8192/test.wasm:wasm-function[180]:0x20bd5 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd947 wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3 runtime.beforeIdle@http://localhost:8192/test.wasm:wasm-function[139]:0x134e9 runtime.findrunnable@http://localhost:8192/test.wasm:wasm-function[540]:0x76612 runtime.schedule@http://localhost:8192/test.wasm:wasm-function[545]:0x78f4a runtime.park_m@http://localhost:8192/test.wasm:wasm-function[548]:0x79dc6 runtime.mcall@http://localhost:8192/test.wasm:wasm-function[847]:0xb90ab runtime.gopark@http://localhost:8192/test.wasm:wasm-function[492]:0x6bd41 time.Sleep@http://localhost:8192/test.wasm:wasm-function[840]:0xb8ac1 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd9ea wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3 runtime.beforeIdle@http://localhost:8192/test.wasm:wasm-function[139]:0x134e9 runtime.findrunnable@http://localhost:8192/test.wasm:wasm-function[540]:0x76612 runtime.schedule@http://localhost:8192/test.wasm:wasm-function[545]:0x78f4a runtime.park_m@http://localhost:8192/test.wasm:wasm-function[548]:0x79dc6 runtime.mcall@http://localhost:8192/test.wasm:wasm-function[847]:0xb90ab runtime.gopark@http://localhost:8192/test.wasm:wasm-function[492]:0x6bd41 time.Sleep@http://localhost:8192/test.wasm:wasm-function[840]:0xb8ac1 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd9ea wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3 runtime.beforeIdle@http://localhost:8192/test.wasm:wasm-function[139]:0x134e9 runtime.findrunnable@http://localhost:8192/test.wasm:wasm-function[540]:0x76612 runtime.schedule@http://localhost:8192/test.wasm:wasm-function[545]:0x78f4a runtime.park_m@http://localhost:8192/test.wasm:wasm-function[548]:0x79dc6 runtime.mcall@http://localhost:8192/test.wasm:wasm-function[847]:0xb90ab runtime.gopark@http://localhost:8192/test.wasm:wasm-function[492]:0x6bd41 time.Sleep@http://localhost:8192/test.wasm:wasm-function[840]:0xb8ac1 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd9ea wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3 runtime.beforeIdle@http://localhost:8192/test.wasm:wasm-function[139]:0x134e9 runtime.findrunnable@http://localhost:8192/test.wasm:wasm-function[540]:0x76612 runtime.schedule@http://localhost:8192/test.wasm:wasm-function[545]:0x78f4a runtime.park_m@http://localhost:8192/test.wasm:wasm-function[548]:0x79dc6 runtime.mcall@http://localhost:8192/test.wasm:wasm-function[847]:0xb90ab runtime.gopark@http://localhost:8192/test.wasm:wasm-function[492]:0x6bd41 time.Sleep@http://localhost:8192/test.wasm:wasm-function[840]:0xb8ac1 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd9ea wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3 runtime.beforeIdle@http://localhost:8192/test.wasm:wasm-function[139]:0x134e9 runtime.findrunnable@http://localhost:8192/test.wasm:wasm-function[540]:0x76612 runtime.schedule@http://localhost:8192/test.wasm:wasm-function[545]:0x78f4a runtime.park_m@http://localhost:8192/test.wasm:wasm-function[548]:0x79dc6 runtime.mcall@http://localhost:8192/test.wasm:wasm-function[847]:0xb90ab runtime.gopark@http://localhost:8192/test.wasm:wasm-function[492]:0x6bd41 time.Sleep@http://localhost:8192/test.wasm:wasm-function[840]:0xb8ac1 main.main@http://localhost:8192/test.wasm:wasm-function[1047]:0xcd9ea wasm_pc_f_loop@http://localhost:8192/test.wasm:wasm-function[896]:0xbbb12 wasm_export_resume@http://localhost:8192/test.wasm:wasm-function[895]:0xbbaf3 _resume@http://localhost:8192/wasm_exec.js:550:23 runtime.scheduleTimeoutEvent/<@http://localhost:8192/wasm_exec.js:307:14 setTimeout handler*runtime.scheduleTimeoutEvent@http://localhost:8192/wasm_exec.js:305:39 runtime.scheduleTimeoutEvent@http://localhost:8192/test.wasm:wasm-function[915]:0xbbda3
|
|
Okay. It does not really seem to be a bug on Go's end, since "Script terminated by timeout" is clearly a failure condition in the first place. All we could do is to make the subsequent crash "fatal error: malloc deadlock" nicer by detecting the situation. However, it is impossible to write such detection without reproducing the issue. So overall I'd also opt for closing the issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
The above is the latest release
What operating system and processor architecture are you using (
go env)?Firefox web browser on Linux
go envOutputWhat did you do?
I refreshed the page containing my WebAssembly app.
What did you expect to see?
App works properly, neither the new page/instance of the app nor the old page/instance of the app crashes. That is to say that the app starts without error but also exits cleanly when the page is being destroyed.
What did you see instead?
first time (malloc deadlock stack trace)
second time (console log + malloc deadlock stack trace)
I'm not sure whether these logs were from the new (post-browser-refresh) instance of the app or the dying (pre-browser-refresh) instance of the app (both logs were from when I refreshed the page). However, my app was completely unresponsive the first time and totally responsive after the second time, implying that the first logs were from the new instance and the second logs were from the dying instance.
The key issue is that
runtime.handleEvent()appears twice in the stack trace, which should be impossible as JS is single threaded, but an exception to that rule may occur when JS is terminating synchronous tasks.It is important to emphacize that this is a very rare, not easily-reproducible issue. I have been developing this particular app for around 5 months and this is the first time I have experienced an error of this nature. Today is the first time I have seen the issue, and it has happened twice so far. The second time, the console had additional info.
The source code of my project is currently private but I would be willing to grant access to any go developers who are curious.
The text was updated successfully, but these errors were encountered: