Proxy Segfault

[alexanderbez]

Perhaps this is user error, but I wanted to write up an issue just to clarify. Notice between the zmq3 Proxy and zmq4Proxy, zmq4 has a for loop where zmq3 does not.

If you instantiate frontend and backend sockets then execute Proxy(frontend, backend), say in a separate goroutine, you would expect that once you close both sockets in the parent process, the Proxy call should exit with an error due to interruption (expected). See: https://libzmq.readthedocs.io/en/zeromq4-1/zmq_proxy.html#toc2

Now, a simple test on a M1 Macos will work every time, however, running this sort of test in a Github actions CI workflow for example, will almost always trigger a segfault:

SIGSEGV: segmentation violation
PC=0x0 m=3 sigcode=1 addr=0x0
signal arrived during cgo execution

goroutine 38 gp=0xc0000a6fc0 m=3 mp=0xc000054e08 [syscall]:
runtime.cgocall(0x5c8800, 0xc0000506b0)
	/opt/hostedtoolcache/go/1.23.3/x64/src/runtime/cgocall.go:167 +0x4b fp=0xc000050688 sp=0xc000050650 pc=0x46c36b
github.com/pebbe/zmq4._C2func_zmq4_proxy(0x7fc71c001450, 0x7fc71c001ce0, 0x0)
	_cgo_gotypes.go:442 +0x55 fp=0xc0000506b0 sp=0xc000050688 pc=0x580a55
github.com/pebbe/zmq4.Proxy.func1(0x1?, 0x1?, 0xc000052040?)
	/home/runner/go/pkg/mod/github.com/pebbe/[email protected]/zmq4.go:1309 +0x89 fp=0xc000050708 sp=0xc0000506b0 pc=0x583b49
github.com/pebbe/zmq4.Proxy(0xc0000da480, 0xc0000da4b0, 0xc000050768?)
	/home/runner/go/pkg/mod/github.com/pebbe/[email protected]/zmq4.go:[130](https://github.com/getoptimum/optimum/actions/runs/11784284140/job/32823150737#step:8:131)9 +0x70 fp=0xc000050738 sp=0xc000050708 pc=0x583a30

My guess is that the first Proxy executes successfully, then the sockets are closed, which then returns an error, but since there is a for loop in zmq4, it'll try again and the sockets will be nil triggering a segfault? Is there a need for a for loop? Why does it exist?

[alexanderbez]

Ok, this doesn't seem to have to do anything with the for loop. Rather, the main thread that calls Close on the sockets ends up setting socket.soc to nil which then gets a nil dereference in Proxy it seems.

I'm still not sure if this is user error, a bug in the go wrapper or a zeromq bug? Again, this only happens when executed in a github actions container.

[pebbe]

Sockets are not thread safe. This a problem in zmq, not in Go. You shouldn't create a socket in one goroutine, and use it in another. You should execute Proxy in the same goroutine where you created the sockets.