-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessing a nil *big.Float after v8 is initialized segfaults #38
Comments
This seems to happen with any type from Go's |
Before v8 is initialized this code from the Go stdlib is run: https://golang.org/src/fmt/print.go#L530 |
This fixes #38 which is more severe that it looks like in the issue. With v8's debug stack trace dumping turned on, the Go signal handling stops working. Go's panic mechanism relies on the SIGSEGV process signal. With v8's stack trace dumping the signal handler of the Go runtime is completely skipped. This means that dereferencing any nil pointer in Go will result in a C stack trace with no information about the error happening in the Go code whatsoever. What is worse, Go's formatter intentionally panics when printing nil pointers in order to recover from the panic and print it as <nil> eventually. Without this change, once v8 is initialized, printing nil pointer will result in a crash. Running this v8 wrapper without this change in a product environment is highly risky. You can read in more detail about this here http://konradreiche.com/posts/a-cautionary-tale-of-cgo-embedding.html
Accessing a
nil
*big.Float
will cause a segfault after v8 has been initialized.Minimum Example
What did I expect?
What am I seeing instead?
The text was updated successfully, but these errors were encountered: