Bug 105846

Summary: Assertion failure @ st_atom_array.c:675 when playing Natural Selection 2
Product: Mesa Reporter: las
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED WONTFIX QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: las
Version: unspecifiedKeywords: have-backtrace
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: glxinfo for 17.3.7
glxinfo for 0b73c8

Description las 2018-04-02 11:38:41 UTC
Created attachment 138488 [details]
glxinfo for 17.3.7

When running the game Natural Selection 2 (http://store.steampowered.com/app/4920/), I will eventually encounter an assertion failure src/mesa/state_tracker/st_atom_array.c:675 (assert(attrib->Ptr)).

I have tried version 17.3.7 and also manually compiling mesa at commit 0b73c8.

I'm running the game with mesa_glthread=true and vblank_mode=0, haven't tried without yet.

I am also using amdgpu driver, instead of the default radeon one for my GPU (R9 280).

I haven't yet noticed any pattern, but considering the quality of the game's support for Linux, I assume Mesa didn't catch an invalid use of the API.
Comment 1 las 2018-04-02 11:39:38 UTC
Created attachment 138489 [details]
glxinfo for 0b73c8
Comment 3 las 2018-04-02 12:08:34 UTC
Can't upload attachment here; got 500 internal server error.
Comment 4 las 2018-04-02 19:40:26 UTC
After some testing, it does not seem to happen when MESA_DEBUG=context and MESA_VERBOSE=all.
Comment 5 Timothy Arceri 2018-04-04 10:48:54 UTC
(In reply to las from comment #2)
> link to coredump (also uploading as attachment):
> https://doc-0o-4k-docs.googleusercontent.com/docs/securesc/
> pum26a1iie2onuvj4oi878g6cm4t7ee5/ogcgqid4h8vlgsdm101jckd6jo5jqqc5/
> 1522663200000/00738005966732616001/00738005966732616001/
> 11no6HF0WfEwwlE2IoeMx6aigsJ-
> 504qp?e=download&nonce=lohv7ot3cnbqm&user=00738005966732616001&hash=29id47asc
> b0lesgtto26eu8r8cmsptdn

I get access denied trying to view this link. Can you try again to upload here? I had to try multiple times yesterday but it eventually worked, otherwise can you place it somewhere with public access?

I tried to run the game but it's missing a library on fedora which it seems needs to be built from source and configured to run as a service or something like that which I'm not willing to mess around with.

Anyway are you able to either build mesa from git or use a ppa (assuming you are using ubuntu) [1] to see if this is still happening in the current dev version of mesa/llvm?

[1] https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/+packages
Comment 6 las 2018-04-04 11:05:47 UTC
Another attempt at sharing my coredump: https://drive.google.com/open?id=11no6HF0WfEwwlE2IoeMx6aigsJ-504qp

I'll also try to upload it here again, although it will probably take a long time (am currently downloading my dump with 0.5 MB/s to upload it here...).

I'll update my local version of mesa to the latest git commit once I can (am not currently on that computer).

Another thing to note: Yesterday I tested for ~1 hour with mesa_glthread=true, and it didn't crash.
Although previously even with mesa_glthread=true, crashes could happen every 30 to 120 minutes, so I can not be completely sure yet, that it is mesa_glthread=true causing it, but I *think* it is. I suppose setting those debug variables just prevented some race condition by causing mesa to run slower.

Also if you still want to attempt to run the game: Try running the game with SDL_AUDIODRIVER=alsa and SDL_VIDEODRIVER=x11, that should fix your problem.
Yes, the devs don't make it easy for linux players to run their game.

PS:
I use Arch Linux.
Comment 7 Timothy Arceri 2018-04-04 12:00:45 UTC
(In reply to las from comment #6)
> Another attempt at sharing my coredump:
> https://drive.google.com/open?id=11no6HF0WfEwwlE2IoeMx6aigsJ-504qp
> 
> I'll also try to upload it here again, although it will probably take a long
> time (am currently downloading my dump with 0.5 MB/s to upload it here...).

Oh certainly don't upload that here :P I thought it was just the backtrace you were trying to upload.

> 
> I'll update my local version of mesa to the latest git commit once I can (am
> not currently on that computer).

Thanks.

> 
> Another thing to note: Yesterday I tested for ~1 hour with
> mesa_glthread=true, and it didn't crash.
> Although previously even with mesa_glthread=true, crashes could happen every
> 30 to 120 minutes, so I can not be completely sure yet, that it is
> mesa_glthread=true causing it, but I *think* it is. I suppose setting those
> debug variables just prevented some race condition by causing mesa to run
> slower.
> 
> Also if you still want to attempt to run the game: Try running the game with
> SDL_AUDIODRIVER=alsa and SDL_VIDEODRIVER=x11, that should fix your problem.
> Yes, the devs don't make it easy for linux players to run their game.

I'm still getting: error while loading shared libraries: libsndio.so.6.1: cannot open shared object file: No such file or directory

At least they have released a 64bit version I guess, so they are trying. The 32bit version was useless.
Comment 8 las 2018-04-05 17:42:45 UTC
So I've tested it for a few hours now, and it does not seem to be happening anymore.
Comment 9 las 2018-04-06 15:59:20 UTC
NVM it just happened again, exact same error too.
Comment 10 las 2018-04-06 21:26:05 UTC
Seems like it's not mesa_glthread causing it. It just happened again with mesa_glthread=false.
Comment 11 las 2018-04-06 21:28:01 UTC
(In reply to Timothy Arceri from comment #5)
> (In reply to las from comment #2)
> > link to coredump (also uploading as attachment):
> > https://doc-0o-4k-docs.googleusercontent.com/docs/securesc/
> > pum26a1iie2onuvj4oi878g6cm4t7ee5/ogcgqid4h8vlgsdm101jckd6jo5jqqc5/
> > 1522663200000/00738005966732616001/00738005966732616001/
> > 11no6HF0WfEwwlE2IoeMx6aigsJ-
> > 504qp?e=download&nonce=lohv7ot3cnbqm&user=00738005966732616001&hash=29id47asc
> > b0lesgtto26eu8r8cmsptdn
> 
> I get access denied trying to view this link. Can you try again to upload
> here? I had to try multiple times yesterday but it eventually worked,
> otherwise can you place it somewhere with public access?
> 
> I tried to run the game but it's missing a library on fedora which it seems
> needs to be built from source and configured to run as a service or
> something like that which I'm not willing to mess around with.
> 
> Anyway are you able to either build mesa from git or use a ppa (assuming you
> are using ubuntu) [1] to see if this is still happening in the current dev
> version of mesa/llvm?
> 
> [1] https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/+packages

So yeah, it still happens with or without mesa_glthread as of commit 7728720f07a1f0931d7d394d5842de3803e9192b.

I need to do more testing to find out if setting either MESA_VERBOSE or MESA_DEBUG prevents it, as it seems like it's not happening as often as before (perhaps due to a game update?).
Comment 12 las 2018-04-06 22:53:32 UTC
Just crashed with MESA_VERBOSE=all and MESA_DEBUG=context, but I got a nice error message:
Mesa: User error: GL_INVALID_OPERATION in glVertexAttribPointer(non-VBO array)
ns2_linux: ../src/mesa/state_tracker/st_atom_array.c:675: setup_non_interleaved_attribs: Assertion `attrib->Ptr' failed.
Comment 13 Timothy Arceri 2018-04-10 05:22:30 UTC
(In reply to las from comment #12)
> Just crashed with MESA_VERBOSE=all and MESA_DEBUG=context, but I got a nice
> error message:
> Mesa: User error: GL_INVALID_OPERATION in glVertexAttribPointer(non-VBO
> array)
> ns2_linux: ../src/mesa/state_tracker/st_atom_array.c:675:
> setup_non_interleaved_attribs: Assertion `attrib->Ptr' failed.

It's likely a game bug considering the error message but this could be confirmed if you grab an apitrace [1] of the crash and upload it to google drive (or somewhere like that) and link to it from here.

https://github.com/apitrace/apitrace/wiki/Steam
Comment 14 las 2018-04-10 13:02:41 UTC
I haven't gotten an apitrace yet, although I am now 99% sure that it's a bug in the game, since another user had the issue with the proprietary nvidia drivers.

I'll close this now, since it obviously isn't something Mesa should attempt to fix.

Thread on the official forums by said user: https://forums.unknownworlds.com/discussion/154226/linux-random-segfaults

I also got the same segfault in libc.so when I was just using the mesa libs from the arch repository, probably because assertions weren't included in that version.

Thanks for your help though, it was much appreciated!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.