7 Days to Die Crashing on connection

OS Name/Version: Debian 12

Product Name/Version: AMP Release “Decadeus” v2.4.6.6, built 05/10/2023 11:56

Problem Description: Whenever a user connects to the server, it crashes

Got a SIGSEGV while executing native code. This usually indicates
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3514) : Trying to close low level socket support, but we still have sockets open!
a fatal error in the mono runtime or one of the native libraries
used by your application.
Native stacktrace:
2023-10-28T07:00:28 129.907 INF [Steamworks.NET] NET: P2PSessionRequest from: 76561198193721350
0x7fc6ad915062 - /AMP/seven-days-to-die/294420/7DaysToDieServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so :
0x7fc6ad8bdd3d - /AMP/seven-days-to-die/294420/7DaysToDieServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so :
0x7fc6ad843250 - /AMP/seven-days-to-die/294420/7DaysToDieServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so :
0x7fc6e677bfd0 - /lib/x86_64-linux-gnu/libc.so.6 :
0x7fc4af8cc7bb - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af3f2103 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af3f9190 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af619214 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af615b89 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae864303 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae86521a - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae866103 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae866b61 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae71fbb0 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4ae91dcbd - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4aea8d3c2 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4aea8a128 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4aea8c928 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4aea8cf58 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af57346a - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af571541 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af571c3b - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc4af575a05 - /AMP/seven-days-to-die/linux64/steamclient.so :
0x7fc6e67c9044 - /lib/x86_64-linux-gnu/libc.so.6 :
0x7fc6e6848860 - /lib/x86_64-linux-gnu/libc.so.6 : __clone
Telemetry Dumper:
Thread 0x7fc4c9bf86c0 may have been prematurely finalized* Assertion at mono-threads.c:702, condition `info' not met, function:mono_thread_info_current,
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3514) : Trying to close low level socket support, but we still have sockets open!
Shutdown handler: cleanup.

Steps to reproduce:

  • Step 1: create a new 7d2d alpha 21.1 server instance
  • Step 2: start instance
  • Step 3: connect and it will crash the server

Actions taken to resolve so far: tried disabling steamnetworking, however that just made it so the server was unable to connect entirely.

Just information
This error has been reported multiple times in the last 24 hours.

Users report that the error persists even after a fresh installation.
This sounds like corrupted files.

Thank god this is happening to someone else. I’ve been pulling my hair out, trying to get this server back up and running for the last two days.

I can also confirm this issue. Ubuntu 20.04.

One note: if I try to connect through my local network, it works fine.

But once I try to connect through the public IP, the server crashes with the same errors as the OP.

I am having the same issue. I agree with Pres1dente’s note that it seems to be some kind of file corruption, but I don’t think it’s in the 7d2d files themselves. Here is my logic.

I had an existing server fail with this error, like the OG states, new instances have the same issue.

I had one server that was running a copy of the 7d2d files from a few weeks back, it was running mods and not updating automatically. That server still works, even when I remove the mod files. I tried coping all of the 7d2d files from the working instance to a new instance but it still fails.

Something is wrong other than with the 7d2d files themselves.

Any updates on this issue? Has anyone found a resolution?

From Discord:

If you have the Mono Native Crash error. You can either Fetch the latest template in AMP and make a new instance, or add the following ports. You must ensure they are continuous with the Server and Steam Port.

1. Select the instance from ADS.
2. Click Edit Ports
3. Add 3 new UDP ports. If the Server and Steam Port is 26900, make these 26901, 26902, and 26903. Follow the same +1, +2, +3 pattern to match whatever your Server and Steam Port is. This is just an example.
4. Inside the instance, search for Disabled and set the SteamNetworking to disabled

Despite an overcontrolling and arrogant insistence that this was a “game developer issue” and a demand tha any discussion of alternatives be stopped at the risk of a ban, the root cause of the problem here is that the AMP defaults for endpoints for 7DTD are in the 27000 range - and overlap with conditionally used ports reserved by Steam itself.

A discussion with SylenThunder (on both the 7DTD forums and the 7DTD discord) revealed this and also some problematic issues with AMP itself (both technical and administrative).

Moving the endpoints into the 31000 range stopped the problem immediately.

I originally pushed back on this solution since I had four servers running on endpoints 27015, 27018, 27021, and 27024 but SylenThunder explained the conflict potential had been there all along and only showed up occasionally when Steam needed those ports.

Moving all four servers to the 31000 range (and no other changes) solved the problem with the servers.

Not much at all other than personnel changes is going to solve the problem on the Discord channel.

When I asked for how he knew this was a “game dev problem” I literally got back “Because I’m just that good” for a response.

Given how monumentally wrong that arrogant, power-drunk fool was, if CC has any influence at all over that Discord, they might want to consider a personnel change there.

If the game is using other ports that can’t be configured or adjusted, that really is a problem with the game devs not allowing sufficient flexibility. Crashing in the event of port conflicts is also a upstream failure. These are not things that should cause an application to fall over.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.