I gave 1.27 from experimental a quick try and it seems this issue is solved there already. Thanks for the quick fix!

@cwagn are you using Linux on your server?

Glad to hear @Corse!

In T190201#2778233, @bzed wrote:

https://github.com/bzed/dayz-append-fix/ - here is a workaround until its fixed properly.

@Geez fyi: Append is broken for File and FileStream

@Corse I only know the expansion atm mod, that's writing JSON files with a single write, that always worked. All mods that append data were broken, including basic things like log files. They were entry dinner a long time, so I think aliens for simple files was broken since a longer time.

With the workaround in CF in place it's not super critical anymore, at least if you don't have other mods that append data to Filestreams.
You can check your log, stderr should have a line for each modified function call.

The workaround I've posted in https://feedback.bistudio.com/T190201 also fixes that error for me.

In T190201#2778249, @SirAdef wrote:

In T190201#2778233, @bzed wrote:

https://github.com/bzed/dayz-append-fix/ - here is a workaround until its fixed properly.

Some workaround has been added to CF too

• Added a workaround for player loading under Linux due to DayZ bug T190201 (FileMode.APPEND without function)

https://github.com/bzed/dayz-append-fix/ - here is a workaround until its fixed properly.

@Geez I don't want to put pressure on you - but currently every linux server is broken due to that. When are you going to fix it?

In T189830#2777643, @fraky wrote:

Hi,

I moved the server from Linux to Windows 10 with the same configuration and it works there. It's a problem in Linux, as you wrote.

In T189290#2776759, @Corse wrote:

Since the update the server has mostly been stable but I am seeing a new behavior. Now instead of the server crashing, some players will log in and then crash to a 0xc0000005 error. When this happens, the server freezes on the number of players and will continue reporting that number, being unresponsive. No crash logs, it just hangs until it's restarted.

It seems only some players are affected by this. For most, everything is fine. Only some players have this happen, and the freeze and crash for them is random and then they are unable to log back in unless their entry in playerdb is wiped.

This is after a completely fresh install and wipe. Currently hosting on centos 9

So with the following code

FileHandle handle;
for (int i = 0; i < 2; i++)
{
    handle = OpenFile("$profile:testraw.bin", FileMode.APPEND);
    if (handle) {
        Print("DEBUG APPEND - TEST");
        FPrint(handle, "TEST APPEND");
        CloseFile(handle);
    } else {
        Print("DEBUG FAILED TO OPEN FOR APPEND");
    }
}

@Geez More testing (thanks to @lava76 ) shows that append is also broken for a normal FileHandle.
Also a plain vanilla chernarus seems to have issues with persistance (things don't despawn in time and similar things), so my impression is its broken for the server in general. This is a really major issue, please fix it asap!

+1 from me, just stumbled upon this ticket. I rarely play on official due to cheaters. There are good and well working community servers that take care of the issues.
BE is not really helping, they don't seem to be able to track cheaters properly and I also know about false positives - and there is no way to get this issue solved.
Its far from optimal - and without community servers I would not be playing DayZ anymore.

In T189830#2775168, @lava76 wrote:

No, it's very much related. The muzzle index being wrong on load is just an effect of the bug.

I've moved that into https://feedback.bistudio.com/T190201 - the muzzle error is a bug on its own.

I think this might need to go into a bug report on its own, this one is really about a bug in weapon/muzzle handling.

@lava76 I've changed the code to

+     FileSerializer s = new FileSerializer();
+         s.Open("$profile:test2.bin", FileMode.WRITE);
+         s.Write("TEST");
+         s.Close()
+     for (int i = 0; i < 2; i++)
+     {
+         s.Open("$profile:test2.bin", FileMode.APPEND);
+         s.Write("TEST");
+         s.Close();
+     }

My first observation is: test.bin does not get written at all on s.Close() - its still empty after the server started.
The server crashes on shutdown and the file is gone (!)
After the restart, the file is empty again...

@lava76 indeed that case crashes on linux. I've debugged that in an older version of https://steamcommunity.com/sharedfiles/filedetails/?id=3381664818 and the mod was rewritten to use proper constructors and super calls as you would do it in c++, which fixed the segfault. The original constructor was in the form as mentioned above, rather simple, some variables in the child class, and the access to the base class segfaulted.

In 1.26 and 1.27 I regularly see a segfault when dayz is shutdown with the rcon shutdown command, but it doesn't seem to appear (or at least less...) when I send a TERM signal. Haven't seen a double free on shutdown yet.

In T189830#2774524, @fraky wrote:

It's the same for me, after restarting the server, health and water are reset to the default 599. and the player's ammo is replenished to a full 20 pieces, if he had less. I'm going to cry in the corner.

@Geez I can provide memory dumps / rpt files, or if it helps I can keep the linux core file next time so you can load it into gdb

I had just a crash (after updating to the last release today), with the same origin. Not a vanilla server though:

@fraky what you are describing sounds like https://github.com/Arkensor/DayZ-CommunityFramework/issues/183 - which actually points to https://feedback.bistudio.com/T189290. The Muzzle error is - at least in my experience - not related to that.

In T189830#2769203, @fraky wrote:

I made a clean new server with only @CF and @VPP and everything works as it should. I assume that the problem mentioned is from the Expansion mod. The expansion guys will have to update it.

@RPowerSpeed @Geez Indeed, completely support that. Loosing players might not be such an issue for those servers that have a long queue usually - but I have lost 90% of the usual players. Regular crashes, necessary wipes (especially due to CF being also broken, with the fix for it needing a wipe), module creators having to work around bugs in DayZ / the server - thats just super annoying. And a big waste of time for those who run the servers. I would rather create something nice for players instead of having to move players or even delete them because they can't login anymore - or with crashing servers its affecting everybody. There are too many open bugs in the client and the server, and its getting more and more frustrating.

Hi @Geez!
Its happening on two servers, they only share CF as mod. There is https://github.com/Arkensor/DayZ-CommunityFramework/issues/183 which only seems to happen during restarts, but I can investigate.

In T189290#2767438, @bzed wrote:

We are seing this regularly on a slightly modded server. Using an admin backpack with 1000 slots crashes sooner or later for sure. Also picking up crates (mmg in this case) seems to trigger it.

Also there is a general persistence bug over restarts, players have bloody hands and 50% health/food when they join (not sure if it is in CF or in the unmodded game). Healing them seems to make this bug here happen much faster.

In T189290#2767329, @M4ketech wrote:

There is two versions. Standard and experimental, BUT all changes should be stable in experimental some time before the update.

I usually test my stuff in experimental, but when update is published, you cant never know if there is some last minute additions and everything is broken... I think Bohemia needs to give time and information to modders, but...

We are seing this regularly on a slightly modded server. Using an admin backpack with 1000 slots crashes sooner or later for sure. Also picking up crates (mmg in this case) seems to trigger it.

Also I came up (actually with the help of chatgpt) with a script (its a hack, yes) that replaces the player's location in players.db. After changing the location the login works as expected.

So I can actually reproduce this:

@Geez @dedmen it might make sense to merge https://feedback.bistudio.com/T182075 and https://feedback.bistudio.com/T93061 into this bug, or at least link them - they are definitely related.

I've also tried OPENSSL_ia32cap=~0x200000200000000 to really make sure its not a mix of hardware / too old openssl - but the issue stays the same.

Mar 01 17:30:59 game002 hashima-server[1326254]: Error decrypting message: error:0406506C:rsa routines:rsa_ossl_private_decrypt:data greater than mod len
Mar 01 17:30:59 game002 hashima-server[1326254]: Error decrypting message: error:04099079:rsa routines:RSA_padding_check_PKCS1_OAEP_mgf1:oaep decoding error

I tried Debian 11 in a podman container, that didn't make a difference.

In T175939#2576945, @rarnold wrote:

Issue started occurring when relocating a server to a new machine and keeping the configs from the old one. RSYNC was used. I suspect keypair mismatch.

After discussing this in the dayz discord, we are pretty sure that this bug and
https://feedback.bistudio.com/T182075
and
https://feedback.bistudio.com/T93061