Natural Selection 2 keeps crashing when shooting

Seems that the game keeps crashing for me with the same error each time. Does anyone else have a similar issue?

All in short this is the error i get from dmesg.
[77133.261726] ns2_linux32[15536]: segfault at 0 ip 00000000f151f3e7 sp 00000000ffac1680 error 4 in[efdc8000+1925000]

I have a video of the issue: (Loading times are bit long)

Steam systeminfo:

nvidia-bug-report.log.gz (190 KB)

Thanks for reporting this issue. what is the game version? Is this issue specific any map? Did you set any game settings? What desktop env you are running like kde, gnome, unity? What is previous driver worked for you? Did you test with latest 343 and 340 drivers ?

I’m running KDE
I tried latest beta driver but this game has been crashing like this all the time since I bought this game in December last year so cannot say any driver has worked for me since.

Also posted this in their forums

Game version Build 268 but had same issues before.
Cannot say if this is only driver or also game issue since the game devs on their forums haven’t been the best guys in responding but would be awesome if you guys could have a look.

About the procedure, fastest way is to start a sandbox game and then start shooting weaponss as in the video.

Best Regards and thanks for taking your time with this.

I would love it if this was an Nvidia issue, because it would be more likely to get fixed. I highly doubt it is though, the game has been a crash prone disaster since the initial Linux port and I don’t think the developers care at all. There was a huge 3-4 month gap where it would segfault on any kernel newer than 3.10…

Internally tracking this issue under Bug 200034424 . Let me know any more information that will help to easily reproduce this issue in-house.


They just released an update v269 with “Fixed some issues with the linux client” Did my test again, could fire and play around with mostly all guns and second i fired the shotgun the game crashed pointing to:
[80138.970641] ns2_linux32[13228]: segfault at 0 ip 00000000f15073e7 sp 00000000ffce0b40 error 4 in[efdb0000+1925000] so in other words no change.

We are able to reproduce this issue and our engineers are working to fix it.

Bit late comment but, im glad to hear it. Thanks for taking your time with this issue.

We have investigated the issue and found that the crash is due to an application bug. It crashes upon calling glDrawElementsInstanced() because it has incorrectly set the vertex attribute pointers to NULL.
Below is a trace of the OpenGL command stream that leads to the crash. You will note that no VBO is bound, and the application gives a NULL pointer to attribute 6, which by itself is enough to trigger the crash. The application also gets GL_INVALID_OPERATION for the next attributes because of this part of the OpenGL specification:
An INVALID_OPERATION error is generated if a non-zero vertex arrayobject is bound, no buffer is bound to ARRAY_BUFFER, and pointer is not NULL.

Looking at the command stream, it’s likely that the call that unbinds the VBO should simply not be there: experiments on our side show that ignoring this call prevents the crash and doesn’t appear to yield rendering artifacts. Of course such experiments are not spec conformant and cannot be integrated to the NVIDIA driver. An end-user might want to try intercepting glBindBuffer(GL_ARRAY_BUFFER, 0) with LD_PRELOAD, and ignoring this call, to work around the issue until the application is fixed.

glBindBuffer(GL_ARRAY_BUFFER, 0);
glVertexAttribPointer(6, 3, GL_FLOAT, 0, 76, (nil));
glVertexAttribDivisor(6, 1);
glVertexAttribPointer(7, 3, GL_FLOAT, 0, 76, 0xc);
// **********
// **********
glVertexAttribDivisor(7, 1);
glVertexAttribPointer(8, 3, GL_FLOAT, 0, 76, 0x18);
// **********
// **********
glVertexAttribDivisor(8, 1);
glVertexAttribPointer(9, 3, GL_FLOAT, 0, 76, 0x24);
// **********
// **********
glVertexAttribDivisor(9, 1);
glVertexAttribPointer(10, 3, GL_FLOAT, 0, 76, 0x30);
// **********
// **********
glVertexAttribDivisor(10, 1);
glDrawElementsInstanced(GL_TRIANGLES, 84, GL_UNSIGNED_SHORT, (nil), 1);

Thanks for all of your help! I linked your response and it seems they are on it. I owe you all a beer or two =)

Best Regards

Would it be possible to see the code you guys used to intercept the gl_BindBuffer()?

Discussion is ongoing in my other thread at their forums:

But seems that it does not work for some, and the game devs seem to be mostly quiet in thread and on twitter they responded that the issue is difficult.

I tried to capture the syscalls with apitrace and VOGL (by Valve) but the issue isn’t reproducible when they are preloaded. Probably because of the low framerate and hence some effects aren’t drawn at all. Without these tools it’s reproducible easily within 2-3 restarts in Sandbox mode. So I’m also interested in logging these calls without affecting the performance. Can you tell what tools do you use to pinpoint the issue? The preloaded library that should prevent the crash for some reason doesn’t override the glBindBuffer function and is never actually called though it’s being loaded properly and the load() function is executed fine.

According to our internal, limited testing, ignoring the glBindBuffer(GL_ARRAY_BUFFER, 0) call from within the driver was enough to work around the issue. It is not a fix, just a way of avoiding the crash until the application is fixed. We do not have a LD_PRELOAD-based glBindBuffer interceptor.

Being a driver implementor we have ways, internally, of tracing the calls that are made, but this feature is unfortunately not public so I cannot help you much. Refer to the trace in my previous comment for the sequence that was found to lead to the crash.