nics

Hi all, I wonder how I can get access to the Arma 3 dedicted server dev branch for Linux. The command (quoted a a lot in the context of Windows installations) steamcmd.sh +login <steamlogin> +force_install_dir /home/nic/arma3 +'app_update 233780 -beta development' validate +quit just gives me a binary which is binary equal to the stable version (1.34.128075), the one from Nov 4th. It looks like headless client functionality hasn't been implemented in this version yet, the documented HC-startup commands always start another dedicated server instance. Since you BI-guys explicitly mentioned Linux support in the beginning of this thread, I can't wait to get access to it. Does anybody know how to get the dev branch for Linux? Thank you Nic

The answer is no, since it's not the proxy calling dlsym, but libtbbmalloc already. But good try ;) Furthermore, calling dlsym() is not the only problem. We still have the unitialized memory usage...

"To be able to post links or images your post count must be 1 or greater. You currently have 0 posts." Are you serious? ---------- Post added at 11:39 ---------- Previous post was at 11:38 ---------- Sorry guys for not sharing my information, but I simly haven't been aware of this thread. Thanks to k0rd for pointing me here. @patxitron: In one of my issues, I indeed asserted the assumption that LD_PRELOAD might not work at all. But this had only been an assumption and I've been proven wrong. Sorry for your extra work. For those interested: Every shared obect which calls 'pthread_key_create()' either directly or indirectly from its '.init' will crash arma3server if LD_PRELOADed. The Intel TBB allocators call 'dlsym()' to get access to glibc's malloc and the dl-framework in turn calls 'pthread_key_create()'. To give you some status: My first ticket, http://feedback.arma3.com/view.php?id=18487, simply complains on that costly 'mallinfo()' beast getting called far too often. 'mallinfo()' as implemented by glibc walks all memory-chunks the application ever 'free()'d and thus, consumes a lot of CPU cycles in general. Substituting 'mallinfo()' by a NOP, I observed a performance gain of up to 1000%, especially at mission loading and AI spawning time. The other two tickets, http://feedback.arma3.com/view.php?id=18556 and http://feedback.arma3.com/view.php?id=18706, refer to bugs which stand in the way of LD_PRELOADing the Intel TBB allocators. The Intel TBB allocators, substituting a NOP-'mallinfo()' by themselves, provide an extra performance boost of approx. 10% or more over the NOP-'mallinfo()' substitution alone, at least in my very quick tests I did with 1.16. The first of the two tickets can be regarded as being solved "in principle" in the sense that it is only waiting for BIS to apply a fix. However, it got assigned today, so chances are good that this happens in a timely manner. The second issue on the other hand is harder: While it is easy to reproduce, these kinds of bugs related to unitialized memory are hard to track down in general. I will do my best, but without any access to source code, it is even harder :P What I already know is, that this bug is located somewhere in some parser code and it might happen that solving this could solve some other Heisenbugs which also occur if nothing is LD_PRELOADed at all. We'll see.