log.Printf blocks indefinitely under wasm when called from JS #1088
Description
log.Printf seems to work correctly when used directly in main() but when called from a function which is wrapped with js.FuncOf and in a callback from a browser event it appears to block the first time and then panic the second time. Using fmt.Printf does not appear to have the same issue.
I'm using TinyGo compiled from this commit 2572483
A simple example that reproduces is here: https://github.com/bradleypeabody/tgtesta and the most relevant bits are:
main_wasm.go
func main() {
log.Printf("main() function here\n")
fn := js.FuncOf(func(this js.Value, args []js.Value) interface{} {
fmt.Printf("got into the function\n")
log.Printf("a log.Printf statement 1\n")
return nil
})
js.Global().Get("window").Call("setCallback", fn)
}index.html
// setCallback is called from main.wasm once it is run
function setCallback(f) {
document.getElementById('cbbtn').addEventListener('click', function(e) {
f.call(null, myUint8Array);
});
}
Clicking the button the first time gets to the fmt.Printf (you can see the output in the browser console), but appears to hang at the log.Printf. Clicking again gives:
panic: todo: block on locked mutex
main.wasm:1 Uncaught RuntimeError: unreachable
at runtime._panic (wasm-function[24]:0x18c9)
at (*sync.Mutex).Lock (wasm-function[137]:0xb35c)
at (*log.Logger).Output (wasm-function[167]:0xcfec)
at log.Printf (wasm-function[145]:0xbe59)
at syscall/js.handleEvent (wasm-function[94]:0x5db1)
at runtime.resume$1 (wasm-function[91]:0x55db)
at resume (wasm-function[90]:0x5535)
at global.Go._resume (http://localhost:8844/wasm_exec.js:481:23)
at http://localhost:8844/wasm_exec.js:492:8
at HTMLButtonElement.<anonymous> (http://localhost:8844/:20:5)
If the issue is that there are internal locking things preventing the log package from working correctly, it would be better to panic nice and early upon first use with a clear error message.