I am not sure that a driver rollback will work, but it is probably worth a try, as I have been using Nvidia's binary drivers as well and NS2 used to be playable for me. I have been experiencing this crashing on the first weapon fire since Build 256 was pushed to Steam and have not noticed Nvidia driver updates to fix the problem. Also, for some reason NS2 reset my status on playing through the tutorial - perhaps because I performed the nuke/re-install to see if that would fix the issue.
I have noticed significant frame rendering speed improvement in the newer builds for the Launch and Options screens and I am able to begin the tutorial, but my problem is as described by numerous other posters in this thread. As a marine, whether firing the pistol or rifle, I immediately crash to desktop. I am able to build structures, purchase, and use a Welder but progressing in the tutorial is basically impossible. As a skulk, the crash occurs as soon as I hatch.
Thank you for supporting Linux - I hope this information was useful.
As I have written in an earlier post I have already tried to roll back my drivers, with nvidia 304, 310, 313, 325 and 331 and none of them worked (this was on build 258).. And now i have tried build 259 with nvidia 331 and the result is exactly the same as before, (crash when shooting with assault rifle)..
p.s I will gladly make you another backtrace for build 259 if you guys need it, but you already have two from build 258 so don't know if you need it.
So now we just have to wait 1-2 weeks before we will know if the next build will fix it, and with the enthusiasm they have put into the Linux build so far is will probably take months to fix. (like the LANG=en_US bug did)
Heres to micro updates!! so we don't have to wait weeks or months for bug fixes.
Seriously! There are days when I just wished they hadn't released a Linux build of NS2 at all, the game is sooo not ready yet, and at this point I think they are damaging Linux's reputation as a gaming platform more then helping it.
They could at least write on the Steam store page that the Linux build is early beta so that people know that it might not work for them.
Please make a backtrace @b166erdk it would be most helpful for the devs. (we already have one, but more cannot hurt just in case)
There's a few small bugs already that i'd personally like to see fixed sooner than weeks.. so i don't think it would take very long if there's just a handful.
Nvidia is going to be releasing a new driver for NS2 due to some issues, both graphical artifacts as well as performance.
So here's hoping either a patch from us, or a new driver from them fixes it.
thanks for the guide. I was running the game from the steam client. 1st thing to mention is that "ps -e| grep ns2_linux32" showed me 2 processes, but I was able to kill one of them (kill -9) without any visible effect to the game.
This is my bt from the gdm:
Program received signal SIGSEGV, Segmentation fault.
0xf17c16e6 in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60
(gdb) bt
#0 0xf17c16e6 in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60
#1 0xf17c647d in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60
#2 0xf13a089d in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60
#3 0xf72511c0 in M4::OpenGLDevice::DrawIndexedPrimitives (this=0xe7b1ea90, primitiveType=M4::RenderPrimitiveType_TriangleList, minVertexIndex=0,
numVertices=34, startIndex=0, numPrimitives=28, numInstances=1) at ../Source/Render/OpenGLDevice.cpp:1033
#4 0xf727c4c8 in M4::RenderModelProxy::RenderFaceSet (this=0xae43c568, faceSetIndex=0, numInstances=1) at ../Source/Render/RenderModelProxy.cpp:298
#5 0xf72791c7 in M4::RenderModelArray::RenderFaceSet (this=0xb3757210, faceSetIndex=0) at ../Source/Render/RenderModelArray.cpp:423
#6 0xf7293bd1 in RenderFaceSet (this=<optimized out>, faceSet=...) at ../Source/Render/RenderRenderer.cpp:321
#7 M4::RenderRenderer::RenderFaceSets<M4::RenderModelArray, M4::ObjectRenderer<M4::RenderModelArray> > (this=0xb8a5dda0, context=...,
viewerParams=..., renderer=..., faceSets=0xb31217d8, numFaceSets=1) at ../Source/Render/RenderRenderer.cpp:3422
#8 0xf729098f in M4::RenderRenderer::RenderModelArrays (this=0xb8a5dda0, context=..., viewerParams=..., modelArray=0xff8c3610, numModelArrays=1,
techniqueIndex=1, reverseCulling=false, shadows=false) at ../Source/Render/RenderRenderer.cpp:2624
#9 0xf7291bff in M4::RenderRenderer::RenderObjects (this=0xb8a5dda0, context=..., viewerParams=..., objects=..., techniqueIndex=1,
objectsMask=4294967039) at ../Source/Render/RenderRenderer.cpp:2173
#10 0xf7291f91 in M4::RenderRenderer::RenderObjects (this=0xb8a5dda0, scene=0xbc57eb50, context=..., objects=0xff8c2ec0, camera=..., viewport=...,
techniqueIndex=1, objectsMask=4294967039, zonesMask=4294967295) at ../Source/Render/RenderRenderer.cpp:2996
#11 0xf72924d6 in M4::RenderRenderer::Render (this=0xb8a5dda0, pipeline=0xb09fea20, colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0,
sourceTexture=0x0, sceneSettings=0xb7b37de6, setupSettings=0xff8cf158, scene=0xbc57eb50, time=341.16024780273438, camera=..., viewport=...,
visibleObjects=..., background=0x0) at ../Source/Render/RenderRenderer.cpp:1316
#12 0xf72a6aac in M4::RenderScene::InternalRender (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0,
pipeline=0xb09fea20, camera=..., prevCamera=0x0, viewport=..., renderMask=4294967295, cullingMode=M4::RenderScene_CullingMode_Occlusion,
background=0x0, deltaTime=0.0458374023) at ../Source/Render/RenderScene.cpp:801
#13 0xf72a7681 in M4::RenderScene::InternalRender (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0, camera=
0xb72bb340, _viewport=0x0, background=0x0, deltaTime=0.0458374023) at ../Source/Render/RenderScene.cpp:743
#14 0xf72a7a5c in M4::RenderScene::RenderMainCamera (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0,
camera=0xb72bb340, viewport=0x0, background=0x0, time=341.16024780273438) at ../Source/Render/RenderScene.cpp:698
---Type <return> to continue, or q <return> to quit---
#15 0xf72a7b6e in M4::RenderScene::Render (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, camera=0xb72bb340,
background=0x0, time=341.16024780273438) at ../Source/Render/RenderScene.cpp:481
#16 0x080822e4 in M4::ClientWorld::Render (this=0xb7b35fe0, drawer=..., swapChain=0xe7c26e38) at ../Source/Spark_Client/ClientWorld.cpp:2260
#17 0x0806ca5d in M4::ClientGame::Render (this=0xe7b1f008, swapChain=0xe7c26e38) at ../Source/Spark_Client/ClientGame.cpp:1649
#18 0x0807802a in M4::ClientGame::Update (this=0xe7b1f008, deltaTime=0.047854043999961959) at ../Source/Spark_Client/ClientGame.cpp:926
#19 0x0806be56 in M4::ClientEngine::Update (this=0xf3c7b170, deltaTime=0.047854043999961959) at ../Source/Spark_Client/ClientEngine.cpp:152
#20 0x080bf814 in M4::BaseEngine::RunFrame (this=0xf3c7b170) at ../Source/Spark_Server/BaseEngine.cpp:196
#21 0x080bf840 in M4::BaseEngine::Run (this=0xf3c7b170) at ../Source/Spark_Server/BaseEngine.cpp:160
#22 0x0806a273 in main (argc=<error reading variable: Cannot access memory at address 0x3>,
argv=<error reading variable: Cannot access memory at address 0x7>) at ../Source/ShooterExe/Main.cpp:82
As all others here, the game crashed everytime when shooting. But today I installed a new Linux OS in a savvy way.
Crunchbang Waldorf, which I upgraded to Debian SID with some quirks, and I installed kernel 3.11-6.dmz.1-liquorix-amd64 and Nvidia 325.15 drivers via SMXI.
As all others here, the game crashed everytime when shooting. But today I installed a new Linux OS in a savvy way.
Crunchbang Waldorf, which I upgraded to Debian SID with some quirks, and I installed kernel 3.11-6.dmz.1-liquorix-amd64 and Nvidia 325.15 drivers via SMXI.
There is no crash when shooting.
was the upgrade related to the nvidia driver update, too? just wondering if upgrading it manually from 319.60 to 325.15 is worth the effort.
I don't know if this helps, but it seems to work a lot better for me. I still get the crash, but it is maybe once every few games, and on 1 server I played last night, it didn't happen at all. I have a gtx 670 running the 325.08 drivers. My distro is OpenSUSE 12.3 with the 3.710-1.16 kernel.
I also had those crashes. Sometimes I could play for hours and sometimes my game crashed with my first shot/bite. On average I could play 0.5-1.5 rounds.
The backtrace looked the same as the one from blurec.
But since I upgraded my PC I haven't had a single crash. I only changed hardware, not software!
My new system:
Xeon E3-1230v3 (I think this one doesn't matter)
GTX 760 2G (from GT8800 512MB)
16G RAM (from 4G)
Of course I changed everything from low to high in the graphics options, maybe you could try messing with the graphics options.
It seems there are at least 3 possible sources of this crash, or I am just lucky
I am using Gentoo with 64Bit kernel 3.10.7-gentoo-r1, NVIDIA 325.15 (2 Days with 319.49, which also had no crashes).
My launch options for NS2: "rm -rf .config/Natural\ Selection\ 2/cache && rm -rf ~/.config/Natural\ Selection\ 2/Workshop && LC_ALL=en_US %command%"
Ooops, damn I never looked at the requirements, because I bought it before alpha
I just thought I may be able to help, since this was never an issue on Windows and on builds prior to 257 on Linux, and I had the exact same backtrace.
But since you are right, you should all ignore me
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
The devs have all the info they need a and are working on the issue.
As soon as its fixed and tested and ready for the next patch I will update this thread ;-)
shokksAway from KeyboardJoin Date: 2013-10-14Member: 188698Members
Build 260 doesn't solve the problem... Does the devs really work on it ? There are a lot of new features but this problem didn't solve tis bug anymore after a long time. We bought the game and we are still not able to play it
So now we just have to wait 1-2 weeks before we will know if the next build will fix it, and with the enthusiasm they have put into the Linux build so far is will probably take months to fix. (like the LANG=en_US bug did)
Heres to micro updates!! so we don't have to wait weeks or months for bug fixes.
That was on the November 2, 20 days ago!!
And Shokks started this post on October 14.. Thats 39 days ago.
So now we have build 260, and no fix, that is just fucking amazing!!
With support like this, its no wonder NS2 is dying.. It fucking deserves too.
Guys take down your Linux port, and never come back.. Freaking amateurs!
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited November 2013
I just brought up this issue again before the last patch went out, and as of right now it is well known and reported, (As well as the other linux issues) but is not yet fixed by the devs.
They are very aware that it is preventing some users from actually playing the game, and are working on it.
I have placed all Linux bugs that result in crashing as High Priority
I will update you here as soon as i have more info.
And while i'm just volunteering in here, i want to apologize non the less for the inconvenience this causes in the meantime to those effected.
Well @smeat you were technically underneath the minium requirements as the game calls for a 1 GB GPU, let's not discount that as a possibility
I had not thought of this before, but now it makes sense. My 9600 GT only has 512MB VRAM which is under the minimum spec - so I am guessing this is a buffer issue. I am sort of sad because pre-256 builds of NS2 were playable for me (albeit 30-40fps) and now it is totally unplayable, but I understand that my hardware is old.
I would be interested to learn if others experiencing this problem also have a limited VRAM buffer, either in hardware or through software configs.
That could explain it... although it would be a pity if I couldn't just play with some settings turned down -- and if that's the case a clear warning should be added to the game. It's pretty frustrating to sit waiting for all the loadings and precompilings and prestartings just to have the game crash with no other information.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
Nothing, i am afraid. :-/
It just isn't fixed yet.. believe me I am pestering the devs about it frequently. (so much so i was told to stop :-P)
Will update when i have more
I'll just drop by to mention I believe I also have this issue. When I'm done tinkering with xorg settings I'll try to play around with a core dump and whatnot.
Thanks for advocating for us, IronHorse (and thank the devs for me too!). I'm extremely excited to have this game, and look forward to getting it running.
Comments
edit: @asraniel made a report today with the backtrace so hopefully the devs will have this fixed for the next patch
I have noticed significant frame rendering speed improvement in the newer builds for the Launch and Options screens and I am able to begin the tutorial, but my problem is as described by numerous other posters in this thread. As a marine, whether firing the pistol or rifle, I immediately crash to desktop. I am able to build structures, purchase, and use a Welder but progressing in the tutorial is basically impossible. As a skulk, the crash occurs as soon as I hatch.
Thank you for supporting Linux - I hope this information was useful.
p.s I will gladly make you another backtrace for build 259 if you guys need it, but you already have two from build 258 so don't know if you need it.
So now we just have to wait 1-2 weeks before we will know if the next build will fix it, and with the enthusiasm they have put into the Linux build so far is will probably take months to fix. (like the LANG=en_US bug did)
Heres to micro updates!! so we don't have to wait weeks or months for bug fixes.
Seriously! There are days when I just wished they hadn't released a Linux build of NS2 at all, the game is sooo not ready yet, and at this point I think they are damaging Linux's reputation as a gaming platform more then helping it.
They could at least write on the Steam store page that the Linux build is early beta so that people know that it might not work for them.
Please make a backtrace @b166erdk it would be most helpful for the devs. (we already have one, but more cannot hurt just in case)
There's a few small bugs already that i'd personally like to see fixed sooner than weeks.. so i don't think it would take very long if there's just a handful.
Nvidia is going to be releasing a new driver for NS2 due to some issues, both graphical artifacts as well as performance.
So here's hoping either a patch from us, or a new driver from them fixes it.
Ubuntu 13.10 (64 bit), Kernel Version: 3.11.0-13-generic, Driver: NVIDIA Corporation GeForce GTX 650/PCIe/SSE2, Driver Version: 4.3.0 NVIDIA 319.60, OpenGL Version: 4.3
This is my bt from the gdm:
Program received signal SIGSEGV, Segmentation fault. 0xf17c16e6 in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60 (gdb) bt #0 0xf17c16e6 in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60 #1 0xf17c647d in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60 #2 0xf13a089d in ?? () from /usr/lib32/nvidia-319-updates/libnvidia-glcore.so.319.60 #3 0xf72511c0 in M4::OpenGLDevice::DrawIndexedPrimitives (this=0xe7b1ea90, primitiveType=M4::RenderPrimitiveType_TriangleList, minVertexIndex=0, numVertices=34, startIndex=0, numPrimitives=28, numInstances=1) at ../Source/Render/OpenGLDevice.cpp:1033 #4 0xf727c4c8 in M4::RenderModelProxy::RenderFaceSet (this=0xae43c568, faceSetIndex=0, numInstances=1) at ../Source/Render/RenderModelProxy.cpp:298 #5 0xf72791c7 in M4::RenderModelArray::RenderFaceSet (this=0xb3757210, faceSetIndex=0) at ../Source/Render/RenderModelArray.cpp:423 #6 0xf7293bd1 in RenderFaceSet (this=<optimized out>, faceSet=...) at ../Source/Render/RenderRenderer.cpp:321 #7 M4::RenderRenderer::RenderFaceSets<M4::RenderModelArray, M4::ObjectRenderer<M4::RenderModelArray> > (this=0xb8a5dda0, context=..., viewerParams=..., renderer=..., faceSets=0xb31217d8, numFaceSets=1) at ../Source/Render/RenderRenderer.cpp:3422 #8 0xf729098f in M4::RenderRenderer::RenderModelArrays (this=0xb8a5dda0, context=..., viewerParams=..., modelArray=0xff8c3610, numModelArrays=1, techniqueIndex=1, reverseCulling=false, shadows=false) at ../Source/Render/RenderRenderer.cpp:2624 #9 0xf7291bff in M4::RenderRenderer::RenderObjects (this=0xb8a5dda0, context=..., viewerParams=..., objects=..., techniqueIndex=1, objectsMask=4294967039) at ../Source/Render/RenderRenderer.cpp:2173 #10 0xf7291f91 in M4::RenderRenderer::RenderObjects (this=0xb8a5dda0, scene=0xbc57eb50, context=..., objects=0xff8c2ec0, camera=..., viewport=..., techniqueIndex=1, objectsMask=4294967039, zonesMask=4294967295) at ../Source/Render/RenderRenderer.cpp:2996 #11 0xf72924d6 in M4::RenderRenderer::Render (this=0xb8a5dda0, pipeline=0xb09fea20, colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0, sourceTexture=0x0, sceneSettings=0xb7b37de6, setupSettings=0xff8cf158, scene=0xbc57eb50, time=341.16024780273438, camera=..., viewport=..., visibleObjects=..., background=0x0) at ../Source/Render/RenderRenderer.cpp:1316 #12 0xf72a6aac in M4::RenderScene::InternalRender (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0, pipeline=0xb09fea20, camera=..., prevCamera=0x0, viewport=..., renderMask=4294967295, cullingMode=M4::RenderScene_CullingMode_Occlusion, background=0x0, deltaTime=0.0458374023) at ../Source/Render/RenderScene.cpp:801 #13 0xf72a7681 in M4::RenderScene::InternalRender (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0, camera= 0xb72bb340, _viewport=0x0, background=0x0, deltaTime=0.0458374023) at ../Source/Render/RenderScene.cpp:743 #14 0xf72a7a5c in M4::RenderScene::RenderMainCamera (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, faceIndex=0, camera=0xb72bb340, viewport=0x0, background=0x0, time=341.16024780273438) at ../Source/Render/RenderScene.cpp:698 ---Type <return> to continue, or q <return> to quit--- #15 0xf72a7b6e in M4::RenderScene::Render (this=0xbc57eb50, settings=..., colorTarget=0xe7b19fb8, depthTarget=0xe7c26e68, camera=0xb72bb340, background=0x0, time=341.16024780273438) at ../Source/Render/RenderScene.cpp:481 #16 0x080822e4 in M4::ClientWorld::Render (this=0xb7b35fe0, drawer=..., swapChain=0xe7c26e38) at ../Source/Spark_Client/ClientWorld.cpp:2260 #17 0x0806ca5d in M4::ClientGame::Render (this=0xe7b1f008, swapChain=0xe7c26e38) at ../Source/Spark_Client/ClientGame.cpp:1649 #18 0x0807802a in M4::ClientGame::Update (this=0xe7b1f008, deltaTime=0.047854043999961959) at ../Source/Spark_Client/ClientGame.cpp:926 #19 0x0806be56 in M4::ClientEngine::Update (this=0xf3c7b170, deltaTime=0.047854043999961959) at ../Source/Spark_Client/ClientEngine.cpp:152 #20 0x080bf814 in M4::BaseEngine::RunFrame (this=0xf3c7b170) at ../Source/Spark_Server/BaseEngine.cpp:196 #21 0x080bf840 in M4::BaseEngine::Run (this=0xf3c7b170) at ../Source/Spark_Server/BaseEngine.cpp:160 #22 0x0806a273 in main (argc=<error reading variable: Cannot access memory at address 0x3>, argv=<error reading variable: Cannot access memory at address 0x7>) at ../Source/ShooterExe/Main.cpp:82Crunchbang Waldorf, which I upgraded to Debian SID with some quirks, and I installed kernel 3.11-6.dmz.1-liquorix-amd64 and Nvidia 325.15 drivers via SMXI.
There is no crash when shooting.
was the upgrade related to the nvidia driver update, too? just wondering if upgrading it manually from 319.60 to 325.15 is worth the effort.
Edit: Have not tested any other drivers than 325.15 in my Crunchbang installation.
The backtrace looked the same as the one from blurec.
But since I upgraded my PC I haven't had a single crash. I only changed hardware, not software!
My new system:
Xeon E3-1230v3 (I think this one doesn't matter)
GTX 760 2G (from GT8800 512MB)
16G RAM (from 4G)
Of course I changed everything from low to high in the graphics options, maybe you could try messing with the graphics options.
It seems there are at least 3 possible sources of this crash, or I am just lucky
I am using Gentoo with 64Bit kernel 3.10.7-gentoo-r1, NVIDIA 325.15 (2 Days with 319.49, which also had no crashes).
My launch options for NS2: "rm -rf .config/Natural\ Selection\ 2/cache && rm -rf ~/.config/Natural\ Selection\ 2/Workshop && LC_ALL=en_US %command%"
I hope this information may be helpful.
Update: It seems I was just lucky
I just thought I may be able to help, since this was never an issue on Windows and on builds prior to 257 on Linux, and I had the exact same backtrace.
But since you are right, you should all ignore me
Thanks!
I still haven't been able to play NS2 once
As soon as its fixed and tested and ready for the next patch I will update this thread ;-)
And Shokks started this post on October 14.. Thats 39 days ago.
So now we have build 260, and no fix, that is just fucking amazing!!
With support like this, its no wonder NS2 is dying.. It fucking deserves too.
Guys take down your Linux port, and never come back.. Freaking amateurs!
Arch Linux, nVidia's 331.20 driver, Gnome Shell 3.10.
GTX 650 Ti
8gb Ram
Pentium G2030
Sometimes it works fine for hours, sometimes it crashes on the very first shot. (:|
It got fixed, but I never found out what caused it. Never appeared again ever since, so don't give up guys.
They are very aware that it is preventing some users from actually playing the game, and are working on it.
I have placed all Linux bugs that result in crashing as High Priority
I will update you here as soon as i have more info.
And while i'm just volunteering in here, i want to apologize non the less for the inconvenience this causes in the meantime to those effected.
I would be interested to learn if others experiencing this problem also have a limited VRAM buffer, either in hardware or through software configs.
Thanks again for supporting Linux!
That could explain it... although it would be a pity if I couldn't just play with some settings turned down -- and if that's the case a clear warning should be added to the game. It's pretty frustrating to sit waiting for all the loadings and precompilings and prestartings just to have the game crash with no other information.
Is there any news yet?
It just isn't fixed yet.. believe me I am pestering the devs about it frequently. (so much so i was told to stop :-P)
Will update when i have more
Thanks for advocating for us, IronHorse (and thank the devs for me too!). I'm extremely excited to have this game, and look forward to getting it running.