A texture that loaded earlier is marked missing after a 403 on its re-fetch (white HUD) #1435

New issue

Open

opened 2026-11-04 07:39:16 +00:00 by TheSlowly · 0 comments

TheSlowly commented

2026-11-04 07:39:16 +00:00

Collaborator

A texture that had already loaded once was marked missing (drawn white) after a re-fetch answered 403.

What happened

On the first run of a new build the specialised shader pipelines compile in the background. On this machine that compile pushed the viewer's RSS to 10 GB with 2.3 GB of system memory free, and LLViewerTexture::updateClass logged "Low system memory detected, emergency downrezzing off screen textures". When the compile finished the viewer re-requested the dropped textures. Two HUD textures got Http_403 Forbidden from the asset CDN on that re-fetch, LLTextureFetchWorker::doWork aborted them with "fail harder", and LLViewerFetchedTexture::setIsMissingAsset marked them missing. The HUD, which had looked fine until then, drew those faces white for the rest of the session.

07:24:13Z WARNING LLViewerTexture::updateClass : Low system memory detected, emergency downrezzing off screen textures
07:24:35Z INFO    LLTextureFetchWorker::doWork : HTTP GET failed for: http://asset-cdn.glb.agni.lindenlab.com/?texture_id=24524b83-... Status: Http_403 Reason: 'Forbidden'
07:24:35Z WARNING LLTextureFetchWorker::doWork : 24524b83-... abort: fail harder
07:24:35Z WARNING LLViewerFetchedTexture::setIsMissingAsset : 24524b83-...: Marking image as missing

(same for a second texture in the same second)

What should happen

A texture the viewer fetched successfully earlier in the session is known to exist. One 403 from the CDN on a re-fetch should not turn it permanently white: retry through the region's GetTexture capability (or after a delay), and only mark an asset missing when it has never been fetched.

Also worth a look

Why the first-run pipeline compile needs ~8 GB of RAM, and whether the emergency downrez should spare textures the HUD is currently showing.
Why the CDN answers 403 for a texture it served minutes earlier.

A texture that had already loaded once was marked missing (drawn white) after a re-fetch answered 403. **What happened** On the first run of a new build the specialised shader pipelines compile in the background. On this machine that compile pushed the viewer's RSS to 10 GB with 2.3 GB of system memory free, and `LLViewerTexture::updateClass` logged "Low system memory detected, emergency downrezzing off screen textures". When the compile finished the viewer re-requested the dropped textures. Two HUD textures got `Http_403 Forbidden` from the asset CDN on that re-fetch, `LLTextureFetchWorker::doWork` aborted them with "fail harder", and `LLViewerFetchedTexture::setIsMissingAsset` marked them missing. The HUD, which had looked fine until then, drew those faces white for the rest of the session. ``` 07:24:13Z WARNING LLViewerTexture::updateClass : Low system memory detected, emergency downrezzing off screen textures 07:24:35Z INFO LLTextureFetchWorker::doWork : HTTP GET failed for: http://asset-cdn.glb.agni.lindenlab.com/?texture_id=24524b83-... Status: Http_403 Reason: 'Forbidden' 07:24:35Z WARNING LLTextureFetchWorker::doWork : 24524b83-... abort: fail harder 07:24:35Z WARNING LLViewerFetchedTexture::setIsMissingAsset : 24524b83-...: Marking image as missing ``` (same for a second texture in the same second) **What should happen** A texture the viewer fetched successfully earlier in the session is known to exist. One 403 from the CDN on a re-fetch should not turn it permanently white: retry through the region's GetTexture capability (or after a delay), and only mark an asset missing when it has never been fetched. **Also worth a look** - Why the first-run pipeline compile needs ~8 GB of RAM, and whether the emergency downrez should spare textures the HUD is currently showing. - Why the CDN answers 403 for a texture it served minutes earlier.

TheSlowly added the

bug

status

up-next

labels

2026-11-04 07:39:16 +00:00

TheSlowly self-assigned this

2026-11-04 07:39:16 +00:00

TheSlowly added this to the Slipstream project

2026-11-04 07:39:16 +00:00

TheSlowly referenced this issue from a pull request that will close it,

2026-11-04 23:42:16 +00:00