To see the bug, run 2 instances of the executable. For the first instance, use all the default IPs and ports, say "y" to having a NATComplete Server running, and then have have it listen. For the second instance, I found that it is necessary to change the default local port if you're also testing the other instance on the same machine. And instead of listening, I entered the reported GUID from the first instance so that I could connect to it. This causes both instances to crash.

NatPunchthoughClientFrameworkRequires server: YesDescription: Causes two systems to try to connect to each other at the sametime, to get through routers.

Router2FrameworkRequires server: NoDescription: Connect to a peer we cannot directly connect to using thebandwidth of a shared peer.

UDPProxyClientFrameworkRequires server: YesDescription: Connect to a peer using a shared server connection.

Do you have a server running the NATCompleteServer project? (y/n): Executing UPNPFramework

Failed UPNPFrameworkProceeding to next stage.Executing NatTypeDetectionFramework

Failed NatTypeDetectionFrameworkProceeding to next stage.Executing NatPunchthoughClientFrameworkEnter IP of system NatPunchthroughServer, or press enter for default: Enter port of system NatPunchthroughServer, or press enter for default: Connecting...Enter RakNetGuid of the remote system, which should have already connectedto the server.Or press enter to just listen.

NatPunchthoughClientFrameworkRequires server: YesDescription: Causes two systems to try to connect to each other at the sametime, to get through routers.

Router2FrameworkRequires server: NoDescription: Connect to a peer we cannot directly connect to using thebandwidth of a shared peer.

UDPProxyClientFrameworkRequires server: YesDescription: Connect to a peer using a shared server connection.

Do you have a server running the NATCompleteServer project? (y/n): Executing UPNPFramework

Failed UPNPFrameworkProceeding to next stage.Executing NatTypeDetectionFramework

Failed NatTypeDetectionFrameworkProceeding to next stage.Executing NatPunchthoughClientFrameworkEnter IP of system NatPunchthroughServer, or press enter for default: Enter port of system NatPunchthroughServer, or press enter for default: Connecting...Enter RakNetGuid of the remote system, which should have already connectedto the server.Or press enter to just listen.1404477264336045 Calculating port stride from 66.118.161.138|61111HAS_PORT_STRIDE 0. First external port 12345. Second external port 12345.Starting ID_NAT_PUNCHTHROUGH_REQUEST to guid 1404477264336045.Segmentation fault: 11logoutThe crash happens on line 821 of main.cpp, which is:

for (packet=rakPeer->Receive(); packet; rakPeer->DeallocatePacket(packet), packet=rakPeer->Receive())Specifically, the rakPeer->Receive() part causes the crash.I think this must be a bug with some RakNet code, either with the NATCompleteClient sample or the RakNet library. And it seems to only affect the mac version. I ran the same code on windows and it worked fine.

With a windows computer and a mac computer, both on the same LAN, a NAT Punch through attempt caused the mac version to crash (due to the same reason) while the windows version did not crash, so this issue cannot be the result of 2 executables being run on the same machine.

Can someone please confirm they also get this crash on the mac version (or if it works for you)? Does anyone know the mac-specific fix?