Project

General

Profile

Bug #1879

[Windows] Doomsday randomly fails to start when/after loading shader definitions

Added by danij about 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
Defect
Start date:
2014-10-16
% Done:

50%

Tags:

Description

Startup will sometimes fail at the following point, with no explanation in the log as to what is going on:
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"


Related issues

Related to Bug #1977: Doomsday crashes with Intel ChipsetClosed2015-02-12

Associated revisions

Revision 95d20512 (diff)
Added by skyjake about 5 years ago

Fixed|libcore|String: Out-of-bounds memory access (leading to crash)

String::compareWithCase() was calling the QString constructor with a
specific size with the intention of limiting the size of the string.
However, this constructor does not check for null-termination in this
case.

IssueID #1879

History

#1 Updated by danij about 5 years ago

  • Tags set to Windows

#2 Updated by vermil about 5 years ago

As is my understanding, Dday currently has 4 separate start up issues; AA, shader, Snowberry and mobj list.

I'm currently have an random, but regular occurrences in the latest unstable (1385) where Dday won't start and doesn't even create an out file. In this instance, Dday is getting as far as creating the conflicts.log in order to decide whether any of the loaded add-ons conflict (and it log's that none do).

#3 Updated by skyjake about 5 years ago

  • Subject changed from Doomsday fails to start when loading shader definitions (Windows) to Doomsday fails to start when/after loading shader definitions (Windows)

#4 Updated by skyjake about 5 years ago

This should be re-tested with all the recent threading-related fixes.

#5 Updated by vermil about 5 years ago

I'm afraid that with build 1399 I'm personally still finding Dday will very often not start through Snowberry or even create an out file (Snowberry creates a conflict.log file though every time).

One thing I will say is that I regularly change the loaded pwads/mods/game mode (or install the latest versions of pwads I am working on (i.e overwrite) in snowberry before launching.

#6 Updated by skyjake about 5 years ago

vermil wrote:

Dday will very often not start through Snowberry

Do you mean the behaviour is still random, so that after it fails to start, it will still launch successfully on a subsequent try, with the exact same configuration/Snowberry settings?

#7 Updated by vermil about 5 years ago

It is still random yes, though a lot more common with 1.15 I believe.

Upon pressing play, I get a loading cursor appear for a few seconds and looking in my task manger, Dday does appear in it for a few seconds before disappearing on it's own.

I nearly always load various pwads/mods for testing or playing and always use Snowberry because I find that makes pwad/mod loading easiest.

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

#8 Updated by skyjake about 5 years ago

  • Subject changed from Doomsday fails to start when/after loading shader definitions (Windows) to Doomsday randomly fails to start when/after loading shader definitions (Windows)

#9 Updated by skyjake about 5 years ago

vermil wrote:

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

At least for me on the Mac these hangs were fixed by 2027a13e6b0e7ae, included in build 1402.

#10 Updated by vermil about 5 years ago

skyjake wrote:

vermil wrote:

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

At least for me on the Mac these hangs were fixed by 2027a13e6b0e7ae, included in build 1402.

Indeed, they do seem fixed in 1402; Dday appears to start (i.e appear on the screen), unload and quit a lot lot faster. Very good job.

Now there is only a fraction of a second pause or black screen when Dday first enters Ring Zero or a game after engine start up.

#11 Updated by vermil about 5 years ago

Touch wood, I've also not yet had any issues with Dday failing to start anymore since upgrading to 1402 from 1399 (from half dozen start's to test).

EDIT: Spoke too soon. I just got one.

#12 Updated by skyjake about 5 years ago

  • Status changed from New to In Progress
  • Assignee set to skyjake
  • % Done changed from 0 to 50

#13 Updated by skyjake about 5 years ago

Just pushed another fix for a bug that was causing random crashes during startup. Hopefully this was the only one.

#14 Updated by vermil about 5 years ago

I can report that following the last fix, that I no longer get the crash I was talking about when starting Dday (I've waited a while before reporting in, to see if one occurred).

#15 Updated by vermil about 5 years ago

Obviously, the shader bug this issue was originally still about may still occur (it's not a bug I've personally ever experienced, so I can't comment on it)

#16 Updated by skyjake about 5 years ago

  • Assignee deleted (skyjake)

#17 Updated by skyjake about 5 years ago

Although I don't run Doomsday on Windows very often, I've also stopped having crashes at launch.

vermil wrote:

As is my understanding, Dday currently has 4 separate start up issues; AA, shader, Snowberry and mobj list.

The AA problems are being addressed by disabling FSAA by default, and in the longer term using OpenGL 3.3/4 with officially supported render-to-texture-with-AA features. I don't have any further actions for 1.15 on my todo list regarding AA.

I'm guessing by "shader" you mean the originally reported issue, which I have never reproduced on any system. I have no action plan for this.

What are the Snowberry and mobj list issues, though? Perhaps they need separate reports in the tracker?

#18 Updated by vermil about 5 years ago

1. The Snowberry issue was what I called the crash I was getting above (it was a bug in Dday's start up that only seemed to manifest itself for me, when I ran Dday through Snowberry with multiple add-on's loaded), that now appears to be fixed.

2. The shader issue is a crash several users have reported about Dday crashing at startup with "Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/", being the last line in the out file.

Sometimes it's been discovered that the OpenGL version of users experiencing this crash wasn't sufficient for running Dday on and co-incidently, the next part of Dday's start up is the OpenGL check (why isn't the OpenGL check both done before shaders are loaded or detailed in the out file in default level verbosity?).

I personally don't experience this crash.

3. The mobj list crash was something DaniJ mentioned to me as both another possible crash and also a possible alternative reason for the crash mentioned in 2.

4. AA, you have detailed above. Thinking about it now, could this also be the cause of 2.

So I suppose there may not actually be 4 separate start up issues, but possibly only 2, one of which appears to have been fixed.

#19 Updated by skyjake almost 5 years ago

  • Subject changed from Doomsday randomly fails to start when/after loading shader definitions (Windows) to [Windows] Doomsday randomly fails to start when/after loading shader definitions

#20 Updated by skyjake almost 5 years ago

  • Related to Bug #1977: Doomsday crashes with Intel Chipset added

#21 Updated by danij almost 5 years ago

The only remaining issue that I'm seeing from the original report is the delayed minimum OpenGL version check. You are absolutely correct that Doomsday should be testing this long before attempting to compile any shaders.

#22 Updated by skyjake almost 5 years ago

danij wrote:

The only remaining issue that I'm seeing from the original report is the delayed minimum OpenGL version check. You are absolutely correct that Doomsday should be testing this long before attempting to compile any shaders.

The OpenGL version check is done as the first thing after the window has materialized, i.e., as soon as the OpenGL context is available. The shaders are not compiled at this time, only much later when somebody attempts to draw geometry. Note that the log entry is about reading the shader definitions, not compiling the shaders themselves.

Also, when we upgrade to OpenGL 3.3, the version will be selected explicitly. In this case, OpenGL will fail to initialize if the right version isn't supported, removing the need for a post-initialization check.

#23 Updated by danij almost 5 years ago

I didn't state or assume otherwise. My only intention was to draw attention to a point raised earlier - the apparent compiling of shaders before the OpenGL version check and caps listing in the log.

My perspective on this is - why is Doomsday even processing those definitions when the renderer has not even been set up yet?

#24 Updated by skyjake over 4 years ago

  • Target version changed from 49 to 2.0 – Home UI & Packages

#25 Updated by skyjake about 4 years ago

I have a feeling the FBO setup improvements done in #1977 will help with this issue as well.

#26 Updated by skyjake about 4 years ago

  • Status changed from In Progress to Feedback
  • Assignee set to vermil

#27 Updated by skyjake over 3 years ago

  • Status changed from Feedback to Closed

Closing due to no activity.

Also available in: Atom PDF