I have (Heap) commitment issues. 64bit 2GB Memory Limit?

[DucksAreMagic]

I have been desperately trying to do a deep dive to pinpoint exactly why this application isn't running in wine and I *think* I can't escape the 2GB limit. I have become stuck and am looking for a little help. I am experimenting on a virtual machine in ESXi and have tried each version listed on a new Ubuntu 18.04 instance. I feel like I am missing something. I can watch the memory on htop creep just above 2GB then it will stay there until the application crashes.

OS: Ubuntu 18.04 LTS with xfce installed.

uname -a
Linux dzsaserver 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

file DayZServer_x64.exe
PE32+ executable (GUI) x86-64, for MS Windows

Wine versions attempted:
winehq-stable (4.0.3)
winehq-devel (4.21)
Compile of current git (5.0-rc1)

The wine install has dependancies on i384 libraries so:

Code: Select all

sudo dpkg --add-architecture i386

have been added and I'm wondering if I am binding myself to 32bit by using these libraries even with wine64?

Code: Select all

WINEDEBUG=warn+heap wine64 DayZServer_x64.exe -config=serverDZ.cfg -port=2302 -dologs -adminlog -netlog -freezecheck -BEPath=/home/user/.steam/SteamApps/common/DayZServer/battleye > wine.log 2>&1

wine log:

Code: Select all

0009:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0009:fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
0009:fixme:bcrypt:get_alg_property unsupported property L"PaddingSchemes"
0009:fixme:bcrypt:BCryptOpenAlgorithmProvider unsupported flags 00000020
0009:fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
0009:fixme:bcrypt:get_alg_property unsupported property L"PaddingSchemes"
0009:fixme:bcrypt:BCryptOpenAlgorithmProvider unsupported flags 00000020
0009:fixme:ntdll:EtwEventRegister ({47a9201e-73b0-42ce-9821-7e134361bc6f}, 0x13f0072f0, 0x13f05                    9598, 0x13f059590) stub.
0009:fixme:ntdll:EtwEventRegister ({58a9201e-73b0-42ce-9821-7e134361bc70}, 0x13f0072f0, 0x13f05                    95d0, 0x13f0595c8) stub.
0009:fixme:ntdll:EtwEventRegister ({3fa9201e-73b0-43fe-9821-7e145359bc6f}, 0x13f0072f0, 0x13f05                    9560, 0x13f059558) stub.
0009:fixme:ntdll:EtwEventRegister ({1432afee-73b0-42ce-9821-7e134361b433}, 0x13f0072f0, 0x13f05                    9608, 0x13f059600) stub.
0009:fixme:ntdll:EtwEventRegister ({4372afee-73b0-42ce-9821-7e134361b519}, 0x13f0072f0, 0x13f05                    9640, 0x13f059638) stub.
0009:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntl                    m_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distr                    ibution.
002a:fixme:wbemprox:wbem_locator_ConnectServer unsupported flags
002a:fixme:wbemprox:client_security_SetBlanket 00007F53F85ADD00, 00007F53EEABB1D0, 10, 0, (null                    ), 3, 3, 0000000000000000, 0x00000000
002a:fixme:wbemprox:client_security_Release 00007F53F85ADD00
002a:fixme:wbemprox:enum_class_object_Next timeout not supported
0022:fixme:iphlpapi:NotifyAddrChange (Handle 0x7f53e4e60110, overlapped 0x7f53e4e60118): stub
0022:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0022:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0022:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0022:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0022:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f5262f10000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525eb00000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525c8f0000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525b7e0000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525af50000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525ab00000
0009:warn:heap:HEAP_CreateSubHeap Could not commit 00010000 bytes for sub-heap 0x7f525a8d0000
0009:fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL
0009:warn:heap:HEAP_Decommit Could not decommit 03fc0000 bytes at 0x7f533fc70000 for heap 0xb80                    000
0009:warn:heap:allocate_large_block Could not allocate block for 02000000 bytes

The error on the gui dialogue is:

Out of memory (requested 2548 KB).
footprint 809633507 KB

I have been assuming this is miscalculating b as kb as this would be 809GB

[Cybermax]

Hmm.. Does the BattlEye server actually work as a "server"? Probably some different mechanics than the client version, cos the client does NOT work with wine.. ie. You cannot play a battleye protected game on wine/steam/proton currently. But that does not automatically mean the battleye "server" is dependent on the same things as the client are, and is just providing some service functions not actually checking the server itself.

Anyway, it seems to me you are running 64-bit. It does not seem as you are alone with this problem unless this is you tho: https://www.reddit.com/r/dayz/comments/ ... inding_to/

[DucksAreMagic]

Thanks for your input!

That other link isn't me and it seems like a common problem at the moment. I know that a lot of people are asking for a fix and are unable to get it running. I was hoping to commit myself to finding a definitive root cause though.

The first issue I have hit is the memory allocation which I thought would be related to the memory footprint of a 32 bit system. If everything is running on 64bit mode and the system memory is available to the application what could be causing the failure to allocate/commit? Is there any way of seeing or validating the memory address ranges available to wine as it starts to run or is the only way to dive into the +heap debug log channel?

I've also pinpointed the error message in wine-mirror's github. I'm not a C dev but it looks as though it is allocating memory for a specific processId. I'm also wondering if Linux hard/soft ulimits are preventing the user/application from creating a larger stack, locked memory or something?

If anyone knows any logs to listen to, tools to try, params to check I would appreciate the guidance.

I'm assuming the battleye is the same one used by the client as the server itself just seems to be a modified client running as a server and has many of the client files generated automatically but not used. I may start by attempting to 'remove' battleye from the equation and see if it will run without.

Afew new things to try later, Cheers!