Skip to content

x/exp/shiny: memory corruption on windows #48086

Open
@theinternetftw

Description

@theinternetftw

What version of Go are you using (go version)?

$ go version
go version go1.17 windows/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=%LocalAppData%\go-build
set GOENV=%AppData%\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\dev\lang\go_path\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\dev\lang\go_path
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\dev\lang\go\1.17
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\dev\lang\go\1.17\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\dev\cygwin64\tmp\go-build1333133088=/tmp/go-build -gno-record-gcc-switches

What did you do?

https://gist.github.com/theinternetftw/95151dd990fe955644275e13993ef69e

What did you expect to see?

To never see the "memory corruption!" Println

What did you see instead?

The "memory corruption" Println appears quite regularly. (As did memory corruption of large slices in my actual program)

Discussion

I have stopped this behavior by having shiny not call SendMessage outside of the main os thread.

I stopped major investigation once I fixed it for myself and didn't see any recurrence, but a few thoughts on what might be causing it that may help:

  • Perhaps somehow waiting for SendMessage when it involves a window in particular is what causes the corruption, or when SendMessage takes some time to return a result.

  • It might be relevant that the os thread lock is permanently grabbed by the main driver thread, but lockOSThread is nonetheless called later when the syscall.Syscall family of functions is used.

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.OS-Windows

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions