Stack based slice does not work. about ws HOT 11 CLOSED

What do you mean by 'does not work`? Panic? Error? Compilation error?

from ws.

go version go1.12.4 windows/amd64

Send a text message using a browser-based websocket.

// javascript code:
var message = "Hello WebSocket";
websocket.send(JSON.stringify({"message" : message}) + "\n");

ws.ReadHeader > bts variable always the initial value

The result of modifying the stack based slice code.

from ws.

Hi @limpo1989, looks like you are right. The docs of unsafe.Pointer suggests the same pattern. Thank you, I will fix it this week.

from ws.

@limpo1989 sorry for late action, here the PR.

from ws.

@gobwas The issue don't be fix and low probability to SIGSEGV
go version: go version go1.12.5 windows/amd64
go mod: github.com/gobwas/ws v1.0.2-0.20190519195829-89d0ae05650f

read.go > ws.ReadHeader

  bh := (*reflect.SliceHeader)(unsafe.Pointer(&bts))
  //*bh = reflect.SliceHeader{
  //	Data: uintptr(unsafe.Pointer(&b)),
  //	Len:  2,
  //	Cap:  len(b),
  //}

  bh.Data = uintptr(unsafe.Pointer(&b))
  bh.Len = 2
  bh.Cap = len(b)

The result of modifying the stack based slice code:

from ws.

@limpo1989 but what the difference? I mean, is it just a race and your code still able to get same result (zeroed slice) or there is some compiler hint writing Data field that way? Can we reproduce this somehow by unit test?

from ws.

It is not safe to pass a pointer on the stack to a syscall (fd_windows.go:526). The memory on the stack will be moved when the stack shrinks or expands. But the pointer held in the syscall will not be fixed, the read and write will be undefined behavior.

*bh = reflect.SliceHeader{
	Data: uintptr(unsafe.Pointer(&b)),
	Len:  2,
	Cap:  len(b),
}

$ go build -gcflags '-m -l' unsafe.go
# command-line-arguments
.\unsafe.go:68:17: leaking param: r
.\unsafe.go:84:46: ReadHeader &bts does not escape
.\unsafe.go:86:32: ReadHeader &b does not escape
.\unsafe.go:95:53: ReadHeader &b does not escape
...

bh.Data= uintptr(unsafe.Pointer(&b))
bh.Len=  2
bh.Cap=  len(b)

$ go build -gcflags '-m -l' unsafe.go
# command-line-arguments
.\unsafe.go:91:34: &b escapes to heap
.\unsafe.go:81:3: moved to heap: b
...

from ws.

Unable to reproduce in unit test, because the stack shrink or expansion can not be well controlled, but in my project can be 100% recurring, the following is my screenshot, you can see the memory address is moved, but the data It will still be written to the memory before the move.

from ws.

Hi @limpo1989,

I started to try to figure it out on the windows and wrote a test which grows stack until morestack is called and then prepares read on the unsafe-crafted slice of bytes. Currently it works well on both Linux and Windows, but I will try to dig deeper and write same test for concurrent reads from, say, file or something which involves a system call.

If you have any ideas how to catch this bug let me know.

Also, as you said:

But the pointer held in the syscall will not be fixed, the read and write will be undefined behavior.

Regarding the source code, I see that o.Init(buf) is just saving a pointer to the given buffer, which underlying Data field shoud be updated if the stack moves – am I correct with it? Does syscall itself leads to stack move after storing pointer?

from ws.

Also, could you try to add //go:nosplit directive above the ReadHeader() function to check does this problem really relate to stack moving?

from ws.

Currently I am able to reproduce this:

from ws.