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

Comments

Projects
None yet
3 participants
@dsnet
Copy link
Member

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 label Feb 25, 2017

@dsnet dsnet added this to the Go1.9 milestone Feb 25, 2017

@randall77

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2017

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

This comment has been minimized.

Copy link

commented Feb 28, 2017

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

gopherbot pushed a commit that referenced this issue Feb 28, 2017

cmd/compile: simplify load+op rules
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.
You can’t perform that action at this time.