Skip to content
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

panic in read.typeMap() #4

Open
mkevac opened this issue Nov 23, 2014 · 4 comments
Open

panic in read.typeMap() #4

mkevac opened this issue Nov 23, 2014 · 4 comments

Comments

@mkevac
Copy link

mkevac commented Nov 23, 2014

marko@fedora-server:~/goprojects/src/badoo/bumpd (build_bumpd_1.2.0) $ go get -u github.com/randall77/hprof/dumptodot
marko@fedora-server:~/goprojects/src/badoo/bumpd (build_bumpd_1.2.0) $ dumptodot heapdump $(which bumpd) > heap.dot
panic: interface conversion: interface is nil, not string

goroutine 16 [running]:
runtime.panic(0x56c180, 0xc2084fbec0)
    /home/marko/go/src/pkg/runtime/panic.c:279 +0xf5
github.com/randall77/hprof/read.typeMap(0xc208038240, 0xc208186600, 0xc208186600)
    /home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1012 +0xf37
github.com/randall77/hprof/read.nameWithDwarf(0xc208038240, 0x7fff0edd3369, 0x20)
    /home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1275 +0x8f
github.com/randall77/hprof/read.Read(0x7fff0edd3360, 0x8, 0x7fff0edd3369, 0x20, 0x7fdd21234000)
    /home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1607 +0x5e
main.main()
    /home/marko/goprojects/src/github.com/randall77/hprof/dumptodot/main.go:14 +0xe8

goroutine 19 [finalizer wait]:
runtime.park(0x416320, 0x687470, 0x685fc9)
    /home/marko/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x687470, 0x685fc9)
    /home/marko/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
    /home/marko/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
    /home/marko/go/src/pkg/runtime/proc.c:1445
@randall77
Copy link
Owner

Thanks for the bug report. It looks like there is some incomplete dwarf
information; some dwarf entry has no name.

I don't see how that could have happened, at least for a vanilla go
binary. How was your binary produced? Did you just "go build" it? Does
it use cgo? Is anything else linked explicitly?

On Sun, Nov 23, 2014 at 12:05 AM, Marko Kevac [email protected]
wrote:

marko@fedora-server:/goprojects/src/badoo/bumpd (build_bumpd_1.2.0) $ go get -u github.com/randall77/hprof/dumptodot
marko@fedora-server:
/goprojects/src/badoo/bumpd (build_bumpd_1.2.0) $ dumptodot heapdump $(which bumpd) > heap.dot
panic: interface conversion: interface is nil, not string

goroutine 16 [running]:
runtime.panic(0x56c180, 0xc2084fbec0)
/home/marko/go/src/pkg/runtime/panic.c:279 +0xf5github.com/randall77/hprof/read.typeMap(0xc208038240, 0xc208186600, 0xc208186600)
/home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1012 +0xf37github.com/randall77/hprof/read.nameWithDwarf(0xc208038240, 0x7fff0edd3369, 0x20)
/home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1275 +0x8fgithub.com/randall77/hprof/read.Read(0x7fff0edd3360, 0x8, 0x7fff0edd3369, 0x20, 0x7fdd21234000)
/home/marko/goprojects/src/github.com/randall77/hprof/read/parser.go:1607 +0x5e
main.main()
/home/marko/goprojects/src/github.com/randall77/hprof/dumptodot/main.go:14 +0xe8

goroutine 19 [finalizer wait]:
runtime.park(0x416320, 0x687470, 0x685fc9)
/home/marko/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x687470, 0x685fc9)
/home/marko/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
/home/marko/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
/home/marko/go/src/pkg/runtime/proc.c:1445


Reply to this email directly or view it on GitHub
#4.

@mkevac
Copy link
Author

mkevac commented Nov 24, 2014

Hi. Program uses cgo and have a couple of c libraries statically linked. Rocksdb, libsnappy for example.

@randall77
Copy link
Owner

That is probably the issue then. Those c libraries don't contain dwarf
information that is as clean as the hview tool would like it.

I've pushed a simple bug fix to ignore unnamed entries. Please pull and
try again.

On Mon, Nov 24, 2014 at 12:41 PM, Marko Kevac [email protected]
wrote:

Hi. Program uses cgo and have a couple of c libraries statically linked:
rocksdb, libsnappy from the tip of my tongue.


Reply to this email directly or view it on GitHub
#4 (comment).

@mkevac
Copy link
Author

mkevac commented Nov 29, 2014

It works. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants