Crashes

craigerator

After the latest update, the Linux client crashes at least once during almost every single game I play. The improved hit reg is great, but the game hasn't been less playable for me since it was ported to this OS.

Asraniel

A backtrace from gdb would be ideal to debug the issue. Im on my phone now, but hopefully somebody can tell you how to do that

ceribik

Are you using an nvidia card? If so, what driver version are you using?

craigerator

Yes, I'm using a GTX 970 with driver version 358.16.

ceribik

craigerator wrote: »

Yes, I'm using a GTX 970 with driver version 358.16.

That driver version is very buggy and prone to causing crashes. You can either roll back the driver (if feasible) or avoid common triggers, e.g. alt tabbing to/from ns2.

To confirm that it is indeed the driver, next time you crash, open up a terminal and type "dmesg | tail" (without the quotes). Look for a line similar to:
ns2_linux32[3254]: segfault at 43550208 ip 00000000f60c4400 sp 00000000ffa4e700 error 4 in libnvidia-glcore.so.358.16[f495b000+1b19000]

(particularly the bold parts)

craigerator

Here's a stack trace from gdb that was generated when I bought an exo. Onos and map changes are also especially prone to crashes. I've suspected that the sound system was causing problems for a few months, and this seems to confirm it. Shared.GetEntity(self.idleSound2DId) returns nil instead of an object, but I can't find where that method is declared.

Edit: I forgot to capture the backtrace, so this is just the console output from the crash.

craigerator

Here's a trace of the level change crash. Oddly enough, it's maxing out my 16 gigs of memory.

Edit: Also forgot this one. This is what happens when you try to use gdb while drinking Scotch.

TuxZero

Hi, my story is virtually identical to craigerator. Linux (Ubuntu 14.04), Nvidia GTX 970 (Nvidia proprietary driver 352.63), 16 gig memory and lots of crashes since the recent update. My GDB back-traces dont return anything interesting, just
"[Inferior 1 (process 29119) exited normally]
(gdb) bt
No stack."

However log.txt refers to memory problems:
[612.209] ClientGame::UpdateWorld : Error: Failed to allocate 26624 bytes and will now terminate.

and here is the log.txt from another crash:
[697.358] Unbound/Unknown : Error: Failed to allocate 48480 bytes and will now terminate.

edit: Here are some more log errors
[605.316] MainThread : Error: Failed to allocate 26624 bytes and will now terminate.
[225.645] ClientGame::UpdateWorld : Error: Failed to allocate 26624 bytes and will now terminate.
Seems it always crashes on the same number of bytes, the time it crashed on 48480 bytes I was using physx, medium caching and maybe physics multi-threading in the options.

TuxZero

Oh and in dmesg I have this:
[13691.817345] ns2_linux32[5439]: segfault at 0 ip 00000000f6bd1fad sp 00000000d1749b50 error 6 in libSpark_Core.so[f6a00000+6ed000]

craigerator

Here are a bunch of crashes from last night that really do have backtraces attached.

Out of memory - marine
Out of memory - skulk
Standing in the ready room
Precaching
Corrupt stack
Corrupt stack 2
Fighting in an exo
Flaming an onos

TuxZero

Ok, what fixed this for me was to set the texture quality to medium. I guess its the 32bit memory limit problem. Too bad cause it was working well enough on max graphics until the recent patches.

IronHorse

@TuxZero It's probably the holiday themed content adding to that limit, temporarily.

TuxZero

@IronHorse oops, sorry for late reply. Yes you're probably right, it started when I saw the holiday stuff. I kinda like it on medium now, on high it used to crash infrequently but now, zero crashes. Just one, unrelated issue I get is that they keys get stuck sometimes or become random, maybe its my software keyboard, need to study it some more.

IronHorse

@TuxZero Try this http://forums.unknownworlds.com/discussion/comment/2256635/#Comment_2256635

TuxZero

@IronHorse Oh cool. Didnt see that one, I will test with different input methods, thanks

BOHICA

Would MUCH rather deal with the extra 10 seconds of load time opposed to dealing with ruined games due to red plugs, people leaving (due to red plugs), and game crashes. I've been seeing a LOT of greens lately, but not many have came back due to all these issues. 277 was beautiful. Do this again please.

Wyzcrak

@BOHICA what rookie retention rate would you think satisfactory? What do you think it has been lately?

ghostdlr

Linux server is crashing too .

Holi

Just switched to linux and I can confirm the constant crashing Running everything on low next time I'm playing (core i7 4790k, 16gb ram and geforce gtx 980ti) nvidia driver version 352.63.

I'll post some logs when I crash next time thanks for sharing that command, was kind of bewildered looking for logs here

[15517.106847] ns2_linux32[10419]: segfault at cc51b71c ip 00000000cc51b71c sp 00000000d1753dcc error 15 <--- think it happened within the first minute after I joined filled wooza on tram

Asraniel

try to start ns2 through gdb. Once you crash, make a backtrace and post it here.

Holi

Yeah figured out how to do that but didn't get a crash after 2 games on docking in a row I'll keep at it and try more populated servers again tomorrow, and yet again tomorrow.. Think I can force it with higher res textures.. gonna try that tomorrow

#0 M4::OutOfMemory (
size=<error reading variable: Cannot access memory at address 0xd2150f04>)
at ../Source/Engine/HeapAllocator.cpp:41
#1 0xf749e189 in M4::HeapAllocator::AllocateAligned (
this=<error reading variable: Cannot access memory at address 0xd2150f00>,
size=<error reading variable: Cannot access memory at address 0xd2150f04>,
align=<error reading variable: Cannot access memory at address 0xd2150f08>)
at ../Source/Engine/HeapAllocator.cpp:67
#2 0xf7513064 in M4::ProxyAllocator::AllocateAligned (
this=<error reading variable: Cannot access memory at address 0xd2150f20>,
this@entry=<error reading variable: Cannot access memory at address 0xd2150f1c>,
size=<error reading variable: Cannot access memory at address 0xd2150f24>,
align=<error reading variable: Cannot access memory at address 0xd2150f28>)
at ../Source/Engine/ProxyAllocator.cpp:162

That what you wanted Asraniel? I've never used gdb before if you need more info from the backtrace I'll be happy to oblige