nVidia driver crash bug: Please check your logs!

[vatas]

And I will ask modestly in this thread, what is the game's requirements for opengl?
I have 3 computers at home. one has opengl 3.0 and the game has stopped starting. It's a pity because it has 16gb of ram
The second is a chromebook from opengl 4.1 and the game works but crashes for no reason.
the third macbook m1 opengl 4.1 also crashes.
On a work computer with opengl 4.2 works great

This thread might be relevant to you.

[khai]

I know the Wiki and found only one entry from 2008 that the game is going to opengl. For this I am asking but what? Apple's support ended at 4.1

[Jack97]

mine is not faultymine is not faulty

[inevitable]

cross posting this from yet another bug thread

After a bit of analysis, the fix (for at least some crash scenarios) would be to remove the private field 'prep' here: https://github.com/dolda2000/hafen-clie ... t.java#L49

and eliminate usages of 'this.prep', so that cross-thread command accumulation is eliminated from process() and the possibility of init lambda arriving in a different frame than the draw that needs it is gone

You'll likely want to change prepare(buf) to take the target GLRender and appends into render.gl instead of this.prep; then there's no shared render to interleave into.

This eliminates 3 hazards:
Hazard 1 — this.prep is a shared, multi-writer render
Hazard 2 — buf.ro is published before the data store is written
Hazard 3 — Disposal can interleave with in-flight GLRenders

[inevitable]

cross posting this from yet another bug thread

After a bit of analysis, the fix (for at least some crash scenarios) would be to remove the private field 'prep' here: https://github.com/dolda2000/hafen-clie ... t.java#L49

and eliminate usages of 'this.prep', so that cross-thread command accumulation is eliminated from process() and the possibility of init lambda arriving in a different frame than the draw that needs it is gone

You'll likely want to change prepare(buf) to take the target GLRender and appends into render.gl instead of this.prep; then there's no shared render to interleave into.

This eliminates 3 hazards:
Hazard 1 — this.prep is a shared, multi-writer render
Hazard 2 — buf.ro is published before the data store is written
Hazard 3 — Disposal can interleave with in-flight GLRenders

i tried this patch and still crashed on multiple mobs spawning from loose rocks. i collecting a couple more crash logs and this new crash is not specific to nvidia drivers either.

[Nightdawg]

it feels like the combat JVM crashes are making a comeback

[inevitable]

ok , this PR helps based on my testing, though i'll continue to keep testing https://github.com/dolda2000/hafen-client/pull/22