runtime: invalid pointer found on stack #27278
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
|
@Funzinator - Can you post a sample code with steps for us to reproduce this ? |
|
@heschik |
agnivade
changed the title
agnivade
added
WaitingForInfo
|
@cherrymui oh, true. I thought that adjustpointers was called on the whole stack but I guess it's frame-by-frame. I'll take a look. |
|
...but I will need the source. @Funzinator |
|
It took me a while to strip the source code down to something that I can share and that still has the issue. And that's the output I get: |
|
Thanks. I'm away from my desk this week and this is too much for me to figure out on a laptop. If nobody gets to it before next week I'll take a harder look then. |
agnivade
removed
the
WaitingForInfo
|
The bad pointer is The SSA before deadautoelim looks like deadautoelim found a LocalAddr, v325, is used only in a store, and assumed nothing would read from it, and elided it, without knowing that v327 is also pointing to the same memory. I think this is because LocalAddr (Addr at that time) didn't take memory operand before, when deadautoelim was written. So CSE makd it only one copy of LocalAddr per local variable. But this is no longer true after LocalAddr starts taking memory operand. |
|
Reading the code, I think my argument about LocalAddr is probably not correct. But somehow deadautoelim didn't find .autotmp_100 is used through the v327-v332 path. Still investigating... |
|
Ok, I think I see what's going on. Besides the stores that are elided, the only use of v332 is NilCheck, which is special in that it has no use but deadcode doesn't elide it. deadautoelim didn't count it as a use, so it ends up compiling to nil check uninitialized memory. I think deadautoelim should count nil checks as uses. |
|
Change https://golang.org/cl/131955 mentions this issue: |
I don't think that's quite the right description. |
|
You're right. The nil check applies on the address of some uninitialized memory, not the content. |
|
Seems like a backport candidate. |
I agree. |
|
@gopherbot please backport this fix for a serious compiler bug to 1.10. |
|
Backport issue(s) opened: #27342 (for 1.10). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
|
@heschik I think the bug is introduced in Go 1.11. It doesn't need to be backported to Go 1.10. |
|
Ugh, I'm too sleepy. I'll retarget the backport bug. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What did you do?
I have used blevesearch/bleve in my application and was accessing the index concurrently. One goroutine was indexing documents while another was querying.
At this point in time, I am unable to provide the sources since it's part of a bigger code base. I am trying to isolate it and provide a minimal example and will then update this issue if required.
The code was working fine with go 1.10.4 but isn't with go 1.11.
A similar issue has been filed at blevesearch/bleve#993 but they asked me to create an issue here instead because of
runtime.morestack().I have bisected the issue by recompiling my application with particular commits from the golang git repository.
The first commit, introducing this crash is f31a18d
What did you expect to see?
The application works fine as it does with 1.10.4 - concurrent access to the cache is possible.
What did you see instead?
The runtime crashes with the following panic:
System details
The text was updated successfully, but these errors were encountered: