Wanderer Demo Crash in 4.1 and 4.2 #119560

New Issue

Daniel Gryningstjerna · 2024-03-16T15:51:14+01:00

2024-03-16 15:51:14 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.67

Blender Version
Broken: version: 4.1.0 Release Candidate, branch: blender-v4.1-release, commit date: 2024-03-14 17:18, hash: 335ff6efab67
Worked: 4.0

Short description of error
Crash after around 5-10 sec when compling eevee shaders in the wanderer demo. Also happens in 4.2 (leagcy Eeevee) This happends if Blender is open dircetly from the portable .zip and not extracted to a seprate folder.

Exact steps for others to reproduce the error
Download 4.1 realse candidate, open it directly from the .zip and open the wanderer .blend file, after around 5-10 sec of eevee shader compliation it crashes. Weirdly enought it does not happen if the .zip of blender-4.1.0-candidate.... has been extracted. This also happens with many other eevee demos as well.

This occurs because OCIO fails to load its configuration (due to the usage of $ in the path) and we end up attempting to use a color processor that is null:

ExceptionCode         : EXCEPTION_ACCESS_VIOLATION
Exception Address     : 0x00007FF6FC680620
Exception Module      : blender.exe
Exception Flags       : 0x00000000
Exception Parameters  : 0x2
	Parameters[0] : 0x0000000000000000
	Parameters[1] : 0x0000000000000000

blender.exe         :0x00007FF6FC680620  OCIOImpl::cpuProcessorIsNoOp
blender.exe         :0x00007FF6FB715680  IMB_colormanagement_transform
blender.exe         :0x00007FF6FB716FD0  colormanage_imbuf_make_linear
blender.exe         :0x00007FF6FB72B4C0  IMB_ibImageFromMemory
blender.exe         :0x00007FF6FB0FF570  load_image_single

2024-03-16 15-56-03.mp4

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.67 **Blender Version** Broken: version: 4.1.0 Release Candidate, branch: blender-v4.1-release, commit date: 2024-03-14 17:18, hash: `335ff6efab67` Worked: 4.0 **Short description of error** Crash after around 5-10 sec when compling eevee shaders in the wanderer demo. Also happens in 4.2 (leagcy Eeevee) This happends if Blender is open dircetly from the portable .zip and not extracted to a seprate folder.![image](/attachments/c0e0588a-6154-48b9-9adb-7062cb6c5091) **Exact steps for others to reproduce the error** Download 4.1 realse candidate, open it directly from the .zip and open the wanderer .blend file, after around 5-10 sec of eevee shader compliation it crashes. Weirdly enought it does not happen if the .zip of blender-4.1.0-candidate.... has been extracted. This also happens with many other eevee demos as well. This occurs because OCIO fails to load its configuration (due to the usage of `$` in the path) and we end up attempting to use a color processor that is `null`: ``` ExceptionCode : EXCEPTION_ACCESS_VIOLATION Exception Address : 0x00007FF6FC680620 Exception Module : blender.exe Exception Flags : 0x00000000 Exception Parameters : 0x2 Parameters[0] : 0x0000000000000000 Parameters[1] : 0x0000000000000000 blender.exe :0x00007FF6FC680620 OCIOImpl::cpuProcessorIsNoOp blender.exe :0x00007FF6FB715680 IMB_colormanagement_transform blender.exe :0x00007FF6FB716FD0 colormanage_imbuf_make_linear blender.exe :0x00007FF6FB72B4C0 IMB_ibImageFromMemory blender.exe :0x00007FF6FB0FF570 load_image_single ``` 2024-03-16 15-56-03.mp4

2024-03-16 15-56-03.mp4

2.9 MiB

wanderer.blend

299 MiB

image.png

104 KiB

Daniel Gryningstjerna added the

labels 2024-03-16 15:51:15 +01:00

Richard Antalik commented

2024-03-16 20:32:50 +01:00

Can't reproduce this issue (Linux, RTX 3060). Is it necessary to run Blender from the archive in order to trigger this crash?
If no, can you extract the files and run file debug_log.cmd and upload created files after crash?

Can't reproduce this issue (Linux, RTX 3060). Is it necessary to run Blender from the archive in order to trigger this crash? If no, can you extract the files and run file `debug_log.cmd` and upload created files after crash?

Richard Antalik added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2024-03-16 20:33:00 +01:00

Daniel Gryningstjerna commented

2024-03-17 12:28:26 +01:00

Can't reproduce this issue (Linux, RTX 3060). Is it necessary to run Blender from the archive in order to trigger this crash?
If no, can you extract the files and run file debug_log.cmd and upload created files after crash?

Yes, if the .zip is extracted it works fine, but if its run directly from the .zip withoute extracting like in the video attached it will crash, aslo make sure to test on windows since it might be a platfrom specific issue.

> Can't reproduce this issue (Linux, RTX 3060). Is it necessary to run Blender from the archive in order to trigger this crash? > If no, can you extract the files and run file `debug_log.cmd` and upload created files after crash? Yes, if the .zip is extracted it works fine, but if its run directly from the .zip withoute extracting like in the video attached it will crash, aslo make sure to test on windows since it might be a platfrom specific issue.

Richard Antalik commented

2024-03-17 19:39:48 +01:00

Thanks for info. When Blender was launched, it did print error for missing OCIO config, that could be an issue. Can you navigate to folder where Blender was extracted to (find binary location via task manager) and run the file I suggested?

Daniel Gryningstjerna commented

2024-03-17 20:05:33 +01:00

Thanks for info. When Blender was launched, it did print error for missing OCIO config, that could be an issue. Can you navigate to folder where Blender was extracted to (find binary location via task manager) and run the file I suggested?

It always prints that error on every computer I every used when lanched from portable .zip since forever. Should not make it crash either since it used to work fine to lanch from .zip in erlier versions.

If Blender is extracted from the .zip everthing works fine, so not sure if debug_log.cmd will help to fix the issue? Can debug_log.cmd be used while not extracting anything from the .zip?

> Thanks for info. When Blender was launched, it did print error for missing OCIO config, that could be an issue. Can you navigate to folder where Blender was extracted to (find binary location via task manager) and run the file I suggested? It always prints that error on every computer I every used when lanched from portable .zip since forever. Should not make it crash either since it used to work fine to lanch from .zip in erlier versions. If Blender is extracted from the .zip everthing works fine, so not sure if debug_log.cmd will help to fix the issue? Can debug_log.cmd be used while not extracting anything from the .zip?

Richard Antalik commented

2024-03-18 16:17:39 +01:00

If Blender is extracted from the .zip everthing works fine, so not sure if debug_log.cmd will help to fix the issue? Can debug_log.cmd be used while not extracting anything from the .zip?

I think you should be able to run it from zip file. The running from zip file does actually extract all the files to temp folder, so not sure what is going on there. Also the file won't fix anything, but it can give us more info why this crashes.

> If Blender is extracted from the .zip everthing works fine, so not sure if debug_log.cmd will help to fix the issue? Can debug_log.cmd be used while not extracting anything from the .zip? I think you should be able to run it from zip file. The running from zip file does actually extract all the files to temp folder, so not sure what is going on there. Also the file won't fix anything, but it can give us more info why this crashes.

Jesse Yurkovich commented

2024-03-18 18:57:55 +01:00

WinRAR is problematic because of OpenColorIO, and maybe other things, due to where it places files. WinRAR will extract out to a path that is 1) very long and could be running into Windows path length limits and more importantly 2) uses a path that contains a $ symbol[1].

OpenColorIO uses that symbol to attempt to do path substitution for environment variables and will fail. Anything that triggers Color Management operations will not work correctly as long as such paths are used. It probably won't crash anymore but it used to for some versions.

As for the crash itself, check your %temp% directory for a blender.crash.txt file. That should still be written in any case.

[1]

WinRAR is problematic because of OpenColorIO, and maybe other things, due to where it places files. WinRAR will extract out to a path that is 1) very long and could be running into Windows path length limits and more importantly 2) uses a path that contains a `$` symbol[1]. OpenColorIO uses that symbol to attempt to do path substitution for environment variables and will fail. Anything that triggers Color Management operations will not work correctly as long as such paths are used. It probably won't crash anymore but it used to for some versions. As for the crash itself, check your %temp% directory for a `blender.crash.txt` file. That should still be written in any case. [1] ![winrar_badpath.png](/attachments/4294b54d-fd55-4eec-b6c4-4d5b6a885e58)

winrar_badpath.png

113 KiB

Daniel Gryningstjerna commented

2024-03-19 10:23:52 +01:00

@iss @deadpin Thanks for the help, I will check %temp% for a blender.crash.txt when I come home. I will also test if this is just a winrar issue :)

Daniel Gryningstjerna commented

2024-03-19 19:40:30 +01:00

I checked in %temp% for a blender.crash.txt file after I got it to crash once again, but I was unable to find any blender.crash.txt.

Jesse Yurkovich commented

2024-03-19 19:48:14 +01:00

Is there any recent *.crash.txt file? It might even be wanderer.crash.txt

Is there any recent *.crash.txt file? It might even be `wanderer.crash.txt`

Daniel Gryningstjerna commented

2024-03-19 20:13:46 +01:00

Is there any recent *.crash.txt file? It might even be wanderer.crash.txt

Oh! Thanks! Found this:

> Is there any recent *.crash.txt file? It might even be `wanderer.crash.txt` Oh! Thanks! Found this:

wanderer.crash.txt

39 KiB

Jesse Yurkovich commented

2024-03-19 20:19:44 +01:00

Yeah, it's still having issues in OpenColorIO processing (most likely because of that $ symbol in the path):

ExceptionCode         : EXCEPTION_ACCESS_VIOLATION
Exception Address     : 0x00007FF6FC680620
Exception Module      : blender.exe
Exception Flags       : 0x00000000
Exception Parameters  : 0x2
	Parameters[0] : 0x0000000000000000
	Parameters[1] : 0x0000000000000000

blender.exe         :0x00007FF6FC680620  OCIOImpl::cpuProcessorIsNoOp
blender.exe         :0x00007FF6FB715680  IMB_colormanagement_transform
blender.exe         :0x00007FF6FB716FD0  colormanage_imbuf_make_linear
blender.exe         :0x00007FF6FB72B4C0  IMB_ibImageFromMemory
blender.exe         :0x00007FF6FB0FF570  load_image_single

Yeah, it's still having issues in OpenColorIO processing (most likely because of that `$` symbol in the path): ``` ExceptionCode : EXCEPTION_ACCESS_VIOLATION Exception Address : 0x00007FF6FC680620 Exception Module : blender.exe Exception Flags : 0x00000000 Exception Parameters : 0x2 Parameters[0] : 0x0000000000000000 Parameters[1] : 0x0000000000000000 blender.exe :0x00007FF6FC680620 OCIOImpl::cpuProcessorIsNoOp blender.exe :0x00007FF6FB715680 IMB_colormanagement_transform blender.exe :0x00007FF6FB716FD0 colormanage_imbuf_make_linear blender.exe :0x00007FF6FB72B4C0 IMB_ibImageFromMemory blender.exe :0x00007FF6FB0FF570 load_image_single ```

Ray molenkamp commented

2024-03-19 20:32:53 +01:00

While OCIO may indeed be struggling with the $, the actual crash is our fault, in colormanagement_transform_ex after creating cm_processor it doesn't check for null and doesn't exit early. but goes straight into if (IMB_colormanagement_processor_is_noop(cm_processor)) { which null-derefs and gives you the stack above.

While OCIO may indeed be struggling with the $, the actual crash is our fault, in `colormanagement_transform_ex` after creating cm_processor it doesn't check for null and doesn't exit early. but goes straight into `if (IMB_colormanagement_processor_is_noop(cm_processor)) {` which null-derefs and gives you the stack above.

Daniel Gryningstjerna commented

2024-03-19 20:42:16 +01:00

While OCIO may indeed be struggling with the $, the actual crash is our fault, in colormanagement_transform_ex after creating cm_processor it doesn't check for null and doesn't exit early. but goes straight into if (IMB_colormanagement_processor_is_noop(cm_processor)) { which null-derefs and gives you the stack above.

Yeah the error with OCIO has been there for years as far as I rember when opening Blender withoute extracting it, withoute any crashes. Thanks for taking a look at it! :)

> While OCIO may indeed be struggling with the $, the actual crash is our fault, in `colormanagement_transform_ex` after creating cm_processor it doesn't check for null and doesn't exit early. but goes straight into `if (IMB_colormanagement_processor_is_noop(cm_processor)) {` which null-derefs and gives you the stack above. > > > Yeah the error with OCIO has been there for years as far as I rember when opening Blender withoute extracting it, withoute any crashes. Thanks for taking a look at it! :)

Jesse Yurkovich added

and removed

Needs Information from User

labels 2024-03-19 21:01:55 +01:00

Thomas Dinges added

and removed

labels 2024-03-20 12:00:13 +01:00

Thomas Dinges commented

2024-03-20 12:00:44 +01:00

@brecht @Sergey Hey, could you take a look at this please?

Philipp Oeser added this to the 4.1 milestone 2024-03-20 12:21:00 +01:00

Sergey Sharybin referenced a pull request that will close this issue

2024-03-20 13:03:35 +01:00

Fix #119560: Wanderer Demo Crash in 4.1 and 4.2 #119693

Sergey Sharybin commented

2024-03-20 13:05:40 +01:00

@ThomasDinges Sure!

I've submitted a PR which solves crash by adding a missing null-pointer check: #119693.
It is a simple fix which we can do for 4.1.

I still want to dig into why is it running Blender the way it is described seemingly manages to find some parts of OCIO nut not others, and maybe there will be a way to make it work fully correctly.

@ThomasDinges Sure! I've submitted a PR which solves crash by adding a missing null-pointer check: #119693. It is a simple fix which we can do for 4.1. I still want to dig into why is it running Blender the way it is described seemingly manages to find some parts of OCIO nut not others, and maybe there will be a way to make it work fully correctly.

❤️ 3

Sergey Sharybin referenced this issue from a commit

2024-03-20 14:38:33 +01:00

Fix #119560: Wanderer Demo Crash in 4.1 and 4.2

Sergey Sharybin closed this issue

2024-03-20 14:38:34 +01:00

Blender Bot added

and removed