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

cmd/compile: regression when combining load+op on AMD64 #19284

Closed
dsnet opened this issue Feb 25, 2017 · 2 comments
Closed

cmd/compile: regression when combining load+op on AMD64 #19284

dsnet opened this issue Feb 25, 2017 · 2 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@dsnet
Copy link
Member

dsnet commented Feb 25, 2017

21c71d7 caused a regression.

Using yuin/gopher-lua@eed1c79 it passes on the Go revision before 21c71d7, but fails afterwards.

$ go.dev test github.com/yuin/gopher-lua
--- FAIL: TestLua (5.72s)
	script_test.go:74: runtime error: slice bounds out of range
		stack traceback:
			[G]: in function 'match'
			pm.lua:12: in function 'f1'
			pm.lua:77: in main chunk
			[G]: ?

\cc @TocarIP @randall77

@dsnet dsnet added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 25, 2017
@dsnet dsnet added this to the Go1.9 milestone Feb 25, 2017
@randall77
Copy link
Contributor

This is a bug in gopher-lua. In github.com/yuin/gopher-lua/stringlib.go:365 we have

	mds, err := pm.Find(pattern, *(*[]byte)(unsafe.Pointer(&str)), offset, 1)

Where str is a string. That's not a safe thing to do. The pointer and length of the resulting []byte slice are ok, but the capacity is junk. That slice later gets subsliced at github.com/yuin/gopher-lua/pm/pm.go:591 and the junk capacity makes that slicing fail.

Pure luck that this used to work at all.
I'll open an issue against gopher-lua.

@gopherbot
Copy link
Contributor

CL https://golang.org/cl/37585 mentions this issue.

gopherbot pushed a commit that referenced this issue Feb 28, 2017
There's no need to use @block rules, as canMergeLoad makes sure that
the load and op are already in the same block.
With no @block needed, we also don't need to set the type explicitly.
It can just be inherited from the op being rewritten.

Noticed while working on #19284.

Change-Id: Ied8bcc8058260118ff7e166093112e29107bcb7e
Reviewed-on: https://go-review.googlesource.com/37585
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Feb 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants