

#MAC OS DEBUGGER INTERRUPT CODE CODE#
The solution in my case was to use a semaphore in my code to ensure that all ReadFrom and WriteTo calls had returned before attempting to open a new socket on the same port.

This is due to a mutex around the underlying file descriptor in Go. Meaning that even after calling Close() on a net.PacketConn there is no guarantee that the socket has actually been closed. What it fails to mention is that until that happens, Go will not close the socket. Go documentation does mention that any blocked ReadFrom or WriteTo calls will be unblocked and return errors.

ConclusionĪfter digging through the Go standard library I eventually found my answer. Whew! 😅 Using this tool I was able to see that in fact an existing file descriptor was still bound to the same port when the subsequent bind call was made. Now I can see that file descriptor 0x5 is binding to port 3001. If we look at 3rd and 4th bytes in the above output we see the port number of the socket which is 0x0bb9 (3001). This is the dereferenced pointer to the sockaddr struct. On the next lines we see the output of copyinstr(arg1). Īt the end of the first line we see the 5 file descriptor being used like before. In D, the copyinstr function will dereference a pointer in user space and output the result as a string. With the second argument I am tracing the result of a function called copyinstr. This command is saying, "Execute my Go program, but whenever you see a bind system call invocation, run this D script." In the script itself I'm tracing the first two arguments. This function returns a net.PacketConn interface.Īccording to the Go documentation for PacketConn, the Close method should either close the connection, or return an error: type PacketConn interface ' -f bind In Go we can use the net.ListenPacket method to start listening for UDP packets on a given network address. I wondered, why was this happening if I was closing the sockets ? Understanding UDP in Go Eventually I would receive a "bind: address already in use" error upon the creation a socket.

In my test I created two sockets on localhost with two different ports, read/wrote from them, closed them, and then repeated this several hundred times. When trying to add some unit tests to my code I decided to create one around reconnections. I do most of my programming on a Mac, and I have been working on a project written in Go which makes use of UDP sockets.
#MAC OS DEBUGGER INTERRUPT CODE MAC OS X#
Today I want to talk about an issue I was having with UDP sockets in Go, and how I learned more about my program by making use of two tools that ship with Mac OS X called dtruss, and DTrace.
