regexp: Invalid character class on Windows ARM

[anacrolix]

Go version

master and 1.22 (and probably other versions)

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/anacrolix/Library/Caches/go-build'
GOENV='/Users/anacrolix/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/anacrolix/go/pkg/mod'
GOOS='darwin'
GOPATH='/Users/anacrolix/go'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.3/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.3/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/m4/f67w9zfx1pl386_2yjs7xtkm0000gn/T/go-build3366901238=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I'm using github.com/google/go-cmp on Windows ARM. It was compiled for amd64. This is a playground for it, but obviously it's not cross compiled: https://go.dev/play/p/8a4Kt1DD-al?v=gotip.

What did you see happen?

A panic during init. The init code looks fine. The binary also appears to be loading fine, it just doesn't like this character class.

panic: regexp: Compile(`[_\p{L}][_\p{L}\p{N}]*$`): error parsing regexp: invalid character class range: `\p{L}`

goroutine 1 [running]:
regexp.MustCompile({0x7ff66897b52c, 0x17})
	/opt/homebrew/Cellar/go/1.22.3/libexec/src/regexp/regexp.go:317 +0xb4
github.com/google/go-cmp/cmp/internal/function.init()
	/Users/anacrolix/go/pkg/mod/github.com/google/go-cmp@v0.6.0/cmp/internal/function/func.go:68 +0x7c

What did you expect to see?

go-cmp's init to work normally and main to start.

[anacrolix]

I reported this downstream google/go-cmp#359, but I believe the issue is in go.

[gabyhelp]

Related Issues

• regex Windows panic MustCompile/MatchString #28765 (closed)
• regexp: regex pattern matching error #52460 (closed)
• regexp/syntax: panic: unhandled case in compile - x{2} #68067 (closed)
• cmd/compile: panic during sccp while compiling main runtime error: index out of range [-5] #64826 (closed)
• cmd/go: bootstrap with Go 1.21.x fail at tip, panic: godebug: Value of name not listed in godebugs.All: gotypesalias #64106 (closed)
• runtime: encountered a SIGSEGV during 'go run' in go1.16beta1 #43284 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[anacrolix]

None of the related issues match this problem.

[thanm]

Hi @anacrolix I am having trouble reproducing this problem -- when I build + run your test case on our windows/arm64 builders, it seems to work just fine. I tried both with tip of master and with Go 1.22.4.

Your go env output shows a Darwin machine, just confirming that this is indeed a windows issue and not a Darwin issue? Might help if you could tell me a bit more about the setup/configuration of the windows machine where you're seeing the problem. Thanks.

[anacrolix]

Thanks for looking. Specifically I cross compiled from darwin to windows/amd64, then ran that binary on Windows 11 on windows/arm64.

[thanm]

Still can't reproduce. From my darwin arm64 machine I built the program you listed via

GOOS=windows GOARCH=amd64 go build prog.go

downloaded the resulting executable to a windows/arm64 builder, still works fine. What am I missing?

[mauri870]

I couldn't reproduce as well. This feels like the error you would get by copying the regexp from the internet and some character in the regexp string would have a different encoding. But given this happens with a library upstream I'd say it is probably something to do with the OS.

[anacrolix]

Could it be CGO related? I am linking in a bunch of other stuff, and using a cross compiler (x86_64-unknown-linux-gnu-gcc) for some of those cgo parts.

At a stretch, could it be triggered by some kind of memory or emultation corruption? Are your windows/arm64 instances emulated (mine is).

The (downstream) library you mention is heavily used, AFAICT the character classes it's using are well defined too.

Let me know what else I can provide? Thanks

[thanm]

CGO: sure, I can certainly imagine problems there, but it depends on the code of course.

Are your windows/arm64 instances emulated (mine is).

The Go team windows/arm64 builders are Azure VMs, and I am pretty sure they are backed by actual arm hardware.

[anacrolix]

I'll try to construct a minimal reproduction. Thanks for looking into it