-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: Crash on package init with fatal error: bad pointer in write barrier #15831
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
Comments
/cc @aclements @rsc Write barriers sound like your territory :) @balboah Can you try 1.7 (either from master or from the latest beta/rc) and see if the crash occurs again? I know there have been some changes here in 1.7 |
@quentinmit I have only seen this crash once, and I don't know how to reproduce it. But I will use 1.7 once its released :) |
/cc @RLH, since this is also his territory, and I'll be out of town next week. @balboah, which revision of github.com/google/gopacket are you at? (Specifically, I need to know what github.com/google/gopacket/layers/enums.go:381 refers to, since that line at HEAD clearly doesn't have any write barriers.) It might also be relevant what revision of github.com/thisisnotourname/android-lib you're at. |
@aclements I believe I linked to the actual hash path on github, my Godep says 1b0b789. The android-lib is private unfortunately but there are no magic init going on that I could see |
Thanks, that revision does have a write barrier on line 381 (for my future reference: this line), which happens when writing the value part from the interface returned by What do you mean by there being no "magic init" in android-lib? |
Oh! 0x68686868 is a very specific "bad" pointer. That's the poisonStack value on 32-bit. I bet you just got unlucky and genuinely allocated something at that address. As far as I can tell, there's nothing preventing that from happening. We haven't actually used poisonStack since April 2015, when we switched to 1-bit bitmaps for the stack (and lost the information we would need to poison the stack). I'm not sure if something used to prevent us from legitimately allocating at that address. We should probably just remove poisonStack and the checks against that pointer. |
go version
)?1.6.2
go env
)?Was built for android arm using go 1.6.2 and gomobile githash c435d0b.
When java loads the go library, it caused a crash:
The only
init()
that actually seem to do something is gopacket enumsUnfortunately it has only happened occasionally and I don't know how to reproduce it.
The specific android device in question that it happened on is SM-G355H
I believe this is related to #11689
The text was updated successfully, but these errors were encountered: