bertieb 1 Posted August 24, 2012 Is that the official way to send core dumps to BIS? I have no idea :P The CIT page on reporting issues talks about Windows crashes. I'm not even sure how useful that size of a core dump is. My intention was to put anything that might possibly be useful into the relevant issue on the tracker. The crashes are easy to reproduce (leave it running!) but it's not obvious to me what's causing the glibc errors. I'm guessing that if we had a build with debugging symbols included we could perhaps do more; but I'm sure if there was something else we could do the likes of Dwarden et al would pipe up and say. There's a lot of folk waiting quietly to help. At the moment we're likely best off waiting for the next alpha which will hopefully come next week :) Share this post Link to post Share on other sites
.kju 3244 Posted August 24, 2012 Devs looked into community provided core dumps in the past. Making them available certainly does not hurt. Share this post Link to post Share on other sites
JayC 0 Posted August 24, 2012 I'm hoping that we'll get a response from the Devs on if they need/want the core dumps, and what other information they need from us to help them. Share this post Link to post Share on other sites
Overlord 0 Posted August 24, 2012 A quick google search for glibc detected memory corruption returns about 700 hits. By skimming some of those pages, it all ends up in re-compiling the libs. Did anyone of you try this? The strange thing is some run betas with no problems, while others don't. Last thing, there is no point blaming BIS for corrupted code or anything else if you can't run the official release (blaming noone). Share this post Link to post Share on other sites
JayC 0 Posted August 24, 2012 A quick google search for glibc detected memory corruption returns about 700 hits. By skimming some of those pages, it all ends up in re-compiling the libs. Did anyone of you try this? The strange thing is some run betas with no problems, while others don't. Last thing, there is no point blaming BIS for corrupted code or anything else if you can't run the official release (blaming noone). Most people shouldn't be recompiling glibc on their servers... very bad things can happen if you don't know exactly what you're doing. Most likely the errors we're seeing have to do with BIS code/libs, and not gblic libs on the servers in question, which is why EVERYBODY is seeing crashes (I'm not aware of anybody who is not having crashes using this alpha - if somebody isn't experiencing crashes, please post so we can figure out what you're doing differently than the rest of us). Which 'official release' would you suggest we run? Share this post Link to post Share on other sites
visceralsyn 10 Posted August 24, 2012 First alpha running on OpenSUSE 12.1 without crashing. I tossed Mandriva 2010.2 install, that had been working fine, until the 1.62 patch came along. But since I do not feel compelled to help people who whine about stuff they are given to for free. I see no point in helping, other than 'EVERYBODY' is not crashing. ...Syn... Share this post Link to post Share on other sites
bertieb 1 Posted August 24, 2012 First alpha running on OpenSUSE 12.1 without crashing. I tossed Mandriva 2010.2 install, that had been working fine, until the 1.62 patch came along. I'm confused; does that mean you ran the first 1.62 alpha okay? Is there another pre-1.62 alpha I'm unaware of? But since I do not feel compelled to help people who whine about stuff they are given to for free. I see no point in helping, other than 'EVERYBODY' is not crashing. Fair enough. I reckon a small minority were whining (which admittedly is pretty sad given how much support BIS have given the community but idiots will be idiots) and they've been booted out. Share this post Link to post Share on other sites
FelixLegion 1 Posted August 24, 2012 But since I do not feel compelled to help people who whine about stuff they are given to for free. I see no point in helping, other than 'EVERYBODY' is not crashing. Yeah that's just the type of community atmosphere we need around here. Yay! There's more to it than just the "free" word or debating what the word "supports" means. I believe the point that's taken a long time to get to (with some banned members along the way) is that the Linux-hosting portion of Arma's community -- by either playing in their own organizations or by hosting servers 24/7 for countless public players to play on -- has indeed returned it's own worth financially and helped in perpetuating a cycle of customers back to BIS. This cycle is for everyone's to gain really. Now, as far as I'm concerned, we've already gotten the answer we're looking for and are at this point merely weighing our own (grim) options or scraping around for a backup solution; we're all thinking that at this stage in the game it might not be worth our time to do the whole "BIS scratches are back and we scratch theirs" sort of deal anymore; that it might not be worth the risk believing what's behind the game's feature list reading: "Linux support". It seems they've calculated the decision and we're just finding it difficult to bear. Recall that it's a relationship and one that's been years in the making -- not an easy breakup if you ask me... As any admin prefers, you want your setup to function in a world expectations that you can understand and control to get the best out of it. It's the same reason we all probably prefer to game on the PC! But the future for us right now is shaping up to be an environment where we can no longer prepare for that and because of that you don't just go forward without any regrets. There's a lot at stake. TAW has been running a test server of the alpha version on and off with about the same experience as most admins here, and we're going to continue perusing this and other alternatives on all fronts. And I imagine that's what everyone's doing and what this thread is for. Any and all knowledge that's shared or gained from this forum is accomplished more quickly than any of us could do individually, to include BIS. That is a community and the Arma series wouldn't be where it is today without it. Why do you think all this has stuck such a loud chord around here? Simple answer: community. Share this post Link to post Share on other sites
Vixente 10 Posted August 25, 2012 Most likely the errors we're seeing have to do with BIS code/libs, and not gblic libs on the servers in question, which is why EVERYBODY is seeing crashes (I'm not aware of anybody who is not having crashes using this alpha - if somebody isn't experiencing crashes, please post so we can figure out what you're doing differently than the rest of us) As said in post num. 4 of this thread, so far my server had no crashes. Just like with the first alpha. It is a small server and not many people play in it, but i haven't run with any crashes or issues in any mission when playing with a few people. OS is Debian 64 bit (Squeeze). The only thing i had to do, as suggested by PreedSwe in the first alpha thread, was installing and compiling gcc 4.7. Just that. And after solving some dependance issues, it compiled fine and server binary worked ok. Share this post Link to post Share on other sites
Overlord 0 Posted August 25, 2012 Most people shouldn't be recompiling glibc on their servers... very bad things can happen if you don't know exactly what you're doing.That's why there are server admins. If they don't know what they are doing, they should probably not be server admins...Most likely the errors we're seeing have to do with BIS code/libs, and not gblic libs on the servers in question, which is why EVERYBODY is seeing crashes (I'm not aware of anybody who is not having crashes using this alpha - if somebody isn't experiencing crashes, please post so we can figure out what you're doing differently than the rest of us). Me, among others, have a running server. But you don't seem to care about hints you get, you just keep on blaming BIS for making malware. Which 'official release' would you suggest we run? That would be ARMA 2: OA - Linux Standalone Server 1.60.87589 If you can't get that one running flawlessly, please don't blame others. 1.62's are, as stated by BIS, highly alphas, no point trying them if nothing else work. Share this post Link to post Share on other sites
bertieb 1 Posted August 25, 2012 That's why there are server admins. If they don't know what they are doing, they should probably not be server admins...Me, among others, have a running server. But you don't seem to care about hints you get, you just keep on blaming BIS for making malware. Let's not put words in folks mouths, no-one said anything about malware, we're all just trying to get the alphas to run. That would be ARMA 2: OA - Linux Standalone Server 1.60.87589If you can't get that one running flawlessly, please don't blame others. 1.62's are, as stated by BIS, highly alphas, no point trying them if nothing else work. The last official release (and the betas before 1.62) ran fine. However, these alphas have been crashing with glibc errors; perhaps that's where the confusion has arisen? There's no blame here :) As I understand it what complicates matters is that it's not as straightforward for Steam users to do a rollback of their client, so some people are champing at the bit for a release of 1.62 (some more vociferously than others!). I think it's a bit much to ask everyone to try a recompile of glibc when there's other avenues to be explored and there's no guarantee that will alleviate the problems. Share this post Link to post Share on other sites
eulmer 1 Posted August 25, 2012 (edited) Ok, I've spent a fair amount of time trying to get this to work, and it just doesn't seem to work right except on the platform that the dev did the compile on.. What platform or distro was this, BTW? I tried on RHEL6U2/RHEL5U5/Ubuntu 12.04x32 all seem to have serious issues with glibc. Even back porting gcc 4.7.1 from source builds... If I could suggest that you try and recompile on a standard mainstream platform with tested glibc libraries it might help the community test the server software. One based on Centos which is the basis of a lions share of VPS container hosting services, might be worthwhile and help you sell more copies of the game as there will be a larger hosting community available. That said, building against Centos5 development tools might even be the best platform, as even the most elderly other distos can run SW built on that platform... SLED10/11, OpenVZ base, Virtuozzo, Proxmox,etc... The cost to host this on a rented linux container is a fraction of the cost of a windows virtual.. That's why using the latest-greatest libraries and compilers is something that should be avoided unless absolutely necessary, and if it is, you should bundle the .so libraries to run it with your binaries. Edited August 25, 2012 by eulmer Share this post Link to post Share on other sites
Overlord 0 Posted August 25, 2012 Sorry if I have offended anyone, not my intention at all. Today's situation is not optimal, and I guess most people have upgraded their game to 1.62 anyway. That make all working 1.60 servers off limit. Installing new libs (and other stuff) on Debian/Ubuntu is just like installing a program in Windows. So, if people is uncomfortable upgrading their current distro, I suggest they take a look in that direction. Linux isn't about installing a distro and don't do anything else any more. There are also security patches, which can be a bit more tricky to install than this. As I've stated in several posts, I run 1.62.95946 on 64-bit Ubuntu server 10.04 LTS. Only thing I did, was installing GCC 4.6/7. Yeah, you install GCC, then you install server... Another little thing I did was disabling CWR2 and BE, just to test this version on pure BIS platform. I guess some standalone Islands can't hurt? Hardware is not "State of Art", but reliable and have no problem with 20+ players. Share this post Link to post Share on other sites
JayC 0 Posted August 26, 2012 As stated by the Dev's before, there is a library they are using which requires newer glibc versions than is currently on CentOS 5.x, or even CentOS 6.x... They wouldn't have gone to the trouble of upgrading their official build system if that library wasn't a requirement for moving forward. If you look in the first 1.62 alpha thread they list the exact version of Debian they're running on the build system. The issues with glibc crashes are most likely coding issues inside of the BIS code (or supporting library's) and have little to nothing to do with the Linux distro you're running. I think the chances that 1.62 will ever run on CentOS 5.x are slim and none (based on statements made by the Devs), CentOS 6.x may be possible with this build, if not should be possible in the coming weeks and months as RHEL/CentOS back port glibc. I'm frustrated just as much as you are about the current situation, and the huge performance hit, and cost increase with the possibility of needing to migrate to Windows... but, the glibc crashes don't appear to be distro related, nor glibc related, but most likely coding issues/bugs in the BIS code they are most likely working on. Ok, I've spent a fair amount of time trying to get this to work, and it just doesn't seem to work right except on the platform that the dev did the compile on..What platform or distro was this, BTW? I tried on RHEL6U2/RHEL5U5/Ubuntu 12.04x32 all seem to have serious issues with glibc. Even back porting gcc 4.7.1 from source builds... If I could suggest that you try and recompile on a standard mainstream platform with tested glibc libraries it might help the community test the server software. One based on Centos which is the basis of a lions share of VPS container hosting services, might be worthwhile and help you sell more copies of the game as there will be a larger hosting community available. That said, building against Centos5 development tools might even be the best platform, as even the most elderly other distos can run SW built on that platform... SLED10/11, OpenVZ base, Virtuozzo, Proxmox,etc... The cost to host this on a rented linux container is a fraction of the cost of a windows virtual.. That's why using the latest-greatest libraries and compilers is something that should be avoided unless absolutely necessary, and if it is, you should bundle the .so libraries to run it with your binaries. ---------- Post added at 02:15 ---------- Previous post was at 01:17 ---------- Sorry if I have offended anyone, not my intention at all.Today's situation is not optimal, and I guess most people have upgraded their game to 1.62 anyway. That make all working 1.60 servers off limit. Installing new libs (and other stuff) on Debian/Ubuntu is just like installing a program in Windows. So, if people is uncomfortable upgrading their current distro, I suggest they take a look in that direction. Linux isn't about installing a distro and don't do anything else any more. There are also security patches, which can be a bit more tricky to install than this. As I've stated in several posts, I run 1.62.95946 on 64-bit Ubuntu server 10.04 LTS. Only thing I did, was installing GCC 4.6/7. Yeah, you install GCC, then you install server... Another little thing I did was disabling CWR2 and BE, just to test this version on pure BIS platform. I guess some standalone Islands can't hurt? Hardware is not "State of Art", but reliable and have no problem with 20+ players. Overlord, First, I'm well aware that 1.60GA works great, even some of the 1.60MP betas that came after it are very stable... but, steam users were forced to upgrade to 1.62, and there is not a stable process that an average user can perform to revert to 1.60 on Steam... in our clans case that means 65-75% of the players are stuck on 1.62GA. So we're left trying to figure out how to get these 1.62 alpha's to work. Upgrading packages on Debian and Ubuntu is a piece of cake... CentOS isn't any harder... the problem is that for certain versions of these distro's there are NO patches which upgrade the glibc to the correct version... CentOS 5.x which had been very popular among linux server admins for example can't be upgraded with patching to the correct version of glibc. Compiling glibc upgrades by hand aren't something a novice server admin should be doing (although as stated earlier, chroot is an option - but again not for most novice server admins). I think most of these guys are smart enough to install patches if that was the answer. Share this post Link to post Share on other sites
dontknowhow 33 Posted August 26, 2012 Me, among others, have a running server. But you don't seem to care about hints you get, you just keep on blaming BIS for making malware. My server is also running. I'm the only player, which seems to be the difference. For the record, I have a Debian testing 64 bit. Share this post Link to post Share on other sites
sthalik 10 Posted August 28, 2012 (edited) http://appdb.winehq.org/objectManager.php?sClass=version&iId=26557 (details on how to setup) Edited August 28, 2012 by sthalik Share this post Link to post Share on other sites
dontknowhow 33 Posted August 28, 2012 http://appdb.winehq.org/objectManager.php?sClass=version&iId=26557 (details on how to setup) it doesn't run in a tmux session, requiring an $DISPLAY So to run a server in wine you must have the whole X. Awesome. In the meanwhile I had my first crash Share this post Link to post Share on other sites
sthalik 10 Posted August 28, 2012 Depends on what you mean by "whole X". But no. No physical monitor is required. I run an X server (excellent Xming software) on Windows, not to mention UNIX boxes. Share this post Link to post Share on other sites
=wfl= sgt bilko 10 Posted August 28, 2012 Upgraded to GCC 4.7 Ubuntu 12.04 LTS amd64 gcc-4.7-base:i386 (4.7.0-7ubuntu3) libc6:i386 (2.15-0ubuntu10) libgcc1:i386 (1:4.7.0-7ubuntu3) libstdc++6:i386 (4.7.0-7ubuntu3) zlib1g:i386 (1:1.2.3.4.dfsg-3ubuntu4) Files on server updated from a client running 1.62.0.95248 BAF/PMC folders NOT uploaded to server. No AddOns (client or server) ACR lite is not installed (client or server) BE updated to latest for OA 1.62 Still 2 out of 3 times server crashes immediately. When it starts without immediate crash, it crashes a few minutes into a vanilla warfare mission with: 23:56:46 Mission read. 23:57:39 Game started. Segmentation fault (core dumped) When it crashes immediately, same stuff as before: *** glibc detected *** ./oa_server: double free or corruption (!prev): 0x19848450 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xf74c6e42] ./oa_server[0x8a5917d] ./oa_server[0x8a55941] ./oa_server[0x8a55e58] ./oa_server[0x8a5c280] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf746c4d3] ./oa_server[0x804d7e1] ======= Memory map: ======== 08048000-08f40000 r-xp 00000000 fc:03 78561798 /home/arma2srv/arma2/oa_server 08f40000-08f51000 rw-p 00ef7000 fc:03 78561798 /home/arma2srv/arma2/oa_server 08f51000-08f7f000 rw-p 00000000 00:00 0 0a09a000-19854000 rw-p 00000000 00:00 0 [heap] f7200000-f7221000 rw-p 00000000 00:00 0 f7221000-f7300000 ---p 00000000 00:00 0 f733e000-f733f000 ---p 00000000 00:00 0 f733f000-f7453000 rw-p 00000000 00:00 0 f7453000-f75f2000 r-xp 00000000 fc:00 585 /lib/i386-linux-gnu/libc-2.15.so f75f2000-f75f4000 r--p 0019f000 fc:00 585 /lib/i386-linux-gnu/libc-2.15.so f75f4000-f75f5000 rw-p 001a1000 fc:00 585 /lib/i386-linux-gnu/libc-2.15.so f75f5000-f75f8000 rw-p 00000000 00:00 0 f75f8000-f7614000 r-xp 00000000 fc:00 753 /lib/i386-linux-gnu/libgcc_s.so.1 f7614000-f7615000 r--p 0001b000 fc:00 753 /lib/i386-linux-gnu/libgcc_s.so.1 f7615000-f7616000 rw-p 0001c000 fc:00 753 /lib/i386-linux-gnu/libgcc_s.so.1 f7616000-f761d000 r-xp 00000000 fc:00 5857 /lib/i386-linux-gnu/librt-2.15.so f761d000-f761e000 r--p 00006000 fc:00 5857 /lib/i386-linux-gnu/librt-2.15.so f761e000-f761f000 rw-p 00007000 fc:00 5857 /lib/i386-linux-gnu/librt-2.15.so f761f000-f7622000 r-xp 00000000 fc:00 596 /lib/i386-linux-gnu/libdl-2.15.so f7622000-f7623000 r--p 00002000 fc:00 596 /lib/i386-linux-gnu/libdl-2.15.so f7623000-f7624000 rw-p 00003000 fc:00 596 /lib/i386-linux-gnu/libdl-2.15.so f7624000-f763b000 r-xp 00000000 fc:00 5855 /lib/i386-linux-gnu/libpthread-2.15.so f763b000-f763c000 r--p 00016000 fc:00 5855 /lib/i386-linux-gnu/libpthread-2.15.so f763c000-f763d000 rw-p 00017000 fc:00 5855 /lib/i386-linux-gnu/libpthread-2.15.so f763d000-f7640000 rw-p 00000000 00:00 0 f7640000-f766a000 r-xp 00000000 fc:00 597 /lib/i386-linux-gnu/libm-2.15.so f766a000-f766b000 r--p 00029000 fc:00 597 /lib/i386-linux-gnu/libm-2.15.so f766b000-f766c000 rw-p 0002a000 fc:00 597 /lib/i386-linux-gnu/libm-2.15.so f766c000-f7748000 r-xp 00000000 fc:00 135217 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 f7748000-f7749000 ---p 000dc000 fc:00 135217 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 f7749000-f774d000 r--p 000dc000 fc:00 135217 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 f774d000-f774e000 rw-p 000e0000 fc:00 135217 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 f774e000-f7755000 rw-p 00000000 00:00 0 f7757000-f7758000 rw-p 00000000 00:00 0 f7758000-f7759000 ---p 00000000 00:00 0 f7759000-f775e000 rw-p 00000000 00:00 0 f775e000-f775f000 r-xp 00000000 00:00 0 [vdso] f775f000-f777f000 r-xp 00000000 fc:00 323 /lib/i386-linux-gnu/ld-2.15.so f777f000-f7780000 r--p 0001f000 fc:00 323 /lib/i386-linux-gnu/ld-2.15.so f7780000-f7781000 rw-p 00020000 fc:00 323 /lib/i386-linux-gnu/ld-2.15.so ffb46000-ffb67000 rw-p 00000000 00:00 0 [stack] Aborted (core dumped) Share this post Link to post Share on other sites
dontknowhow 33 Posted August 29, 2012 Depends on what you mean by "whole X". But no. No physical monitor is required. I run an X server (excellent Xming software) on Windows, not to mention UNIX boxes. No, I didn't mean a monitor. I meant that you must run X with wine on your server, and tunnel it to your machine. Quite annoying Share this post Link to post Share on other sites
sthalik 10 Posted August 30, 2012 Well, if BIS make a command-line switch to work with wineconsole, I'll gladly incorporate it into appdb. Share this post Link to post Share on other sites
dontknowhow 33 Posted August 30, 2012 Well, if BIS make a command-line switch to work with wineconsole, I'll gladly incorporate it into appdb. I didn't know wineconsole. That seems to be an interesting option. It would be nice to have it, after all it doesn't have a lot of sense to have a server as a GUI application. I wonder what the performance penalty is with Wine Share this post Link to post Share on other sites
sthalik 10 Posted August 30, 2012 I'm worried about stability more. Wine before 1.0 was pretty infamous for its typical breakage. Remember the Starcraft days... Typical CPU usage is pretty low: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17885 arma 25 5 1745m 413m 6520 S 18.7 10.4 1074:09 arma2oaserver.e And that's when there are people playing. Otherwise it's 1-5%. Stats of one core. I forgot to test Arma.NET and similar stuff for JVM. Did anyone test it under Wine and can confirm it works? It doesn't fit my use-case, hence the request. wineconsole is a conhost.exe emulator. I may be smoking crack, though. Know next to nothing about win32. And yes, disabling $DISPLAY requirement would be a major step forward. Just do it BIS :) Share this post Link to post Share on other sites
PreedSwe 18 Posted August 30, 2012 No, I didn't mean a monitor. I meant that you must run X with wine on your server, and tunnel it to your machine. Quite annoying I dont have any display on my server running wine.. I use Xvfb - virtual framebuffer X server for X... / Preed Share this post Link to post Share on other sites
dontknowhow 33 Posted August 31, 2012 I dont have any display on my server running wine.. I use Xvfb - virtual framebuffer X server for X.../ Preed How do you run winetricks? That needs X Share this post Link to post Share on other sites
