runtime.Caller crashes on large inputs #176
Labels
Comments
|
This issue was closed by revision 0911913. Status changed to Fixed. Merged into issue #-. |
|
Comment 3 by emage@spamcop.net: I'm experiencing this again, at rev 4301:383e139ab09f
My test program:
package main
import "fmt"
import "runtime"
func main() {
for i := int(0); true; i++ {
pc, file, line, ok := runtime.Caller(i);
if !ok {
break
}
fmt.Println(pc, file, line);
}
}
GOOS=linux GOARCH=386
failure is at runtime.Caller+0x121 traceback.c:133
|
http://golang.org/cl/166044 Whoops - only fixed amd64 last time. Status changed to Started. |
|
This issue was closed by revision cf37254. Status changed to Fixed. Merged into issue #-. |
CL https://golang.org/cl/96650043 mentions this issue. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
From the documentation I thought that runtime.Caller(frame) will return false when it is not possible to obtain information - instead it causes program to crash past call stack top : package main import ( "fmt"; "runtime"; "strings" ) func main() { foo() } func foo() { bar() } func bar() { for i := 0; ; i++ { _, file, line, ok := runtime.Caller(i); if ok { path := strings.Split(file, "/", 0); fmt.Printf("%s : %d\n", path[len(path)-1], line); } else { break; } } } results in stacktrace.go : 19 stacktrace.go : 14 stacktrace.go : 10 asm.s : 81 proc.c : 135 Bus error Also, Caller() doc says 'The argument is the number of stack frames to ascend, with 1 identifying the the caller of Caller', while in fact, it looks like 0 is the caller of Caller. http://groups.google.com/group/golang-nuts/t/8626dabf2b80d453The text was updated successfully, but these errors were encountered: