search

REGoth-project / REGoth

OpenSource-Reimplementation of the zEngine, used by the game "Gothic"
GNU General Public License v3.0
630 stars 63 forks source link

Crash on world unloading when using Windows+OpenGL since BGFX update #309

Open markusobi opened 6 years ago

markusobi commented 6 years ago

The game is crashing when switching level via switchlevel console command on windows (release & debug). Affects Gothic 1&2.

It was working in nightly-0.4.9. Since nightly-0.4.16 it is crashing on world switch.

Probably #251 introduced the crash. I tried debugging, but all it gave me was segmentation fault in atioglxx.dll (AMD graphics driver). It might be shader related.

@Kukunin can you have a look at it?

markusobi commented 6 years ago

That commit, that first broke it is https://github.com/REGoth-project/REGoth/pull/251/commits/5305a7d0791b1298c8ae1f20ee1b706c19570272

markusobi commented 6 years ago

The problem is not due to world switch. It happens on all forms of world unloading (also when starting another new game - discarding the current world).

I've narrowed the problem down to the VertexBuffer of the SkeletalMeshAllocator. Somehow the shader still uses data of the GPU vertexbuffer even after it is freed. If the freeing of the VertexBuffer is removed in ~SkeletalMeshAllocator, the crash does not happen.

If the drawing of the skeletal meshes is disabled, the crash does not happen either. (by simply adding continue here)

I even tried delaying the destruction of the SkeletalMeshAllocator by freeing it manually via console long after the World has been deleted. Even then the game crashes in the exact same moment as the VertexBuffer of the SkeletalMeshAllocator is deleted. When no world is loaded the shader program isn't even submitted anymore, the application still crashes. Note that not the deletion is crashing, but the render thread is crashing.

Somehow the shader program is still running?

Kukunin commented 6 years ago

@markusobi thanks for the investigation. Unfortunately, I can't help since I was only a monkey who did the boring job.

markusobi commented 6 years ago

It only crashes due to shader access on BONE_INDICES (a_texcoord5) and LOCAL_POSITIONS_1-4 (a_texcoord1-4). When removing the usages of BONE_INDICES and LOCAL_POSITIONS_1-4, it doesn't crash. The vertex buffer is also accessed when reading WEIGHTS (a_texcoord6), but this somehow doesn't cause a crash.

It is crashing since this bgfx commit GL: Removed VAO support. GL: Removed VAO support.

markusobi commented 6 years ago

I've made some progress:

Crash is happening if a shader accesses all of the the shader variables a_texcoord0, a_texcoord2, .., a_texcoord4 in one shader. The crash happens as soon as the shader is not submitted anymore.

I've also found a workaround: When submitting an additional useless vertex shader program with a valid vertex buffer on each frame, the crash does not happen.

Crash has been observed on the following systems: