Blender crashes with Glass BSDF + Sharp + Linux CPU #88738

New Issue

Anton Raves · 2021-06-02T11:46:10+02:00

Anton Raves commented

2021-06-02 11:46:10 +02:00

System Information
Operating system: Linux-5.12.8-300.fc34.x86_64-x86_64-with-glibc2.33 64 Bits
Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.12.8-300.fc34.x86_64, LLVM 12.0.0) X.Org 3.3 (Core Profile) Mesa 21.1.1

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-01 14:46, hash: 383bc8d9bc
Worked: 2.93.0 beta ba4228bcf7

Short description of error
Blender crashes with Glass BSDF + Sharp + Linux CPU

Exact steps for others to reproduce the error
Launch Blender, set it to Cycles and CPU.

Create a new sphere (Shift - a => m => u)
Create a new material for it and change the shader from "Principled BSDF" to "Glass BSDF"
Start a render and realise you have forgotten to set some additional settings, cancel the render.
Change the "Beckmann" type in the glass shader to "Sharp", this in the properties panel, not using the nodes Editor!
Start another render, let it run a number of tiles (tried around 50, tilesize was set to 32) and cancel again for another change.
Now add a plane (Shift - a => m => p) and move that (g => z => -1) and scale it (s => 20)
Render again and once again realise a setting was forgotten and cancel the render to fix that
Select the sphere again and set a subdivision level of 5 (Ctrl - 5)
Render again and realise another setting was forgotten and cancel the render
Right click the sphere and select "Shade Smooth" and in the properties panel under "Normals", enable the "Auto Smooth" feature.
Render again and one of the steps above will have crashed Blender already.

I went back in the list of archived daily build and found that build ba4228bcf7 from May 28th works as expected, build c369382977 from May 29th and newer, including the Stable release from today, all show the crashing behaviour....

I am including a file that was created with the last working build ba4228bcf7 from May 28th, which renders fine in newer builds upon opening, it is switching steps back and forth (for example removing the subdiv modifier or changing the shader options) that will make the more recent versions crash.

beta_ba4228bcf77e_works.blend

**System Information** Operating system: Linux-5.12.8-300.fc34.x86_64-x86_64-with-glibc2.33 64 Bits Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.12.8-300.fc34.x86_64, LLVM 12.0.0) X.Org 3.3 (Core Profile) Mesa 21.1.1 **Blender Version** Broken: version: 2.93.0, branch: master, commit date: 2021-06-01 14:46, hash: `383bc8d9bc` Worked: 2.93.0 beta `ba4228bcf7` **Short description of error** Blender crashes with Glass BSDF + Sharp + Linux CPU **Exact steps for others to reproduce the error** Launch Blender, set it to Cycles and CPU. - Create a new sphere (Shift - a => m => u) - Create a new material for it and change the shader from "Principled BSDF" to "Glass BSDF" - Start a render and realise you have forgotten to set some additional settings, cancel the render. - Change the "Beckmann" type in the glass shader to "Sharp", this in the properties panel, not using the nodes Editor! - Start another render, let it run a number of tiles (tried around 50, tilesize was set to 32) and cancel again for another change. - Now add a plane (Shift - a => m => p) and move that (g => z => -1) and scale it (s => 20) - Render again and once again realise a setting was forgotten and cancel the render to fix that - Select the sphere again and set a subdivision level of 5 (Ctrl - 5) - Render again and realise another setting was forgotten and cancel the render - Right click the sphere and select "Shade Smooth" and in the properties panel under "Normals", enable the "Auto Smooth" feature. - Render again and one of the steps above will have crashed Blender already. I went back in the list of archived daily build and found that build `ba4228bcf7` from May 28th works as expected, build `c369382977` from May 29th and newer, including the Stable release from today, all show the crashing behaviour.... I am including a file that was created with the last working build `ba4228bcf7` from May 28th, which renders fine in newer builds upon opening, it is switching steps back and forth (for example removing the subdiv modifier or changing the shader options) that will make the more recent versions crash. [beta_ba4228bcf77e_works.blend](https://archive.blender.org/developer/F10154085/beta_ba4228bcf77e_works.blend) ![beta_ba4228bcf77e_works.png](https://archive.blender.org/developer/F10154087/beta_ba4228bcf77e_works.png)

Anton Raves commented

2021-06-02 11:46:10 +02:00

Added subscriber: @Memento

Anton Raves commented

2021-06-02 12:03:53 +02:00

I can not reproduce this problem on two Macintosh laptops (macOS 10.15.7 and 11.4), only on the Linux box I have access to.

Pratik Borhade commented

2021-07-14 08:45:03 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2021-07-14 08:45:03 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Pratik Borhade commented

2021-07-14 08:45:03 +02:00

This comment was removed by @PratikPB2123

*This comment was removed by @PratikPB2123*

Pratik Borhade commented

2021-07-14 08:49:55 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Anton Raves commented

2021-07-14 08:57:18 +02:00

With daily build ae379714e4 I had Blender 3.0.0 Alpha crash at the fifth step / bullet already.

With daily build ae379714e4 I had Blender 3.0.0 Alpha crash at the fifth step / bullet already.

Philipp Oeser commented

2021-07-14 15:43:41 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-07-14 15:43:41 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Philipp Oeser closed this issue

2021-07-14 15:43:41 +02:00

Philipp Oeser commented

2021-07-14 15:43:41 +02:00

Cannot reproduce here

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.33.9000 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 465.31
version: 3.0.0 Alpha, branch: master, commit date: 2021-07-14 09:55, hash: `rB5583d517730f`

Do you get crash logs? https://docs.blender.org/manual/en/dev/troubleshooting/crash.html#linux

The GPU is Terrascale 2, which unfortunately means that this GPU is below the minimum requirements for Blender, so there is no longer support for it. https://www.blender.org/download/requirements/
Installing the latest graphics driver sometimes helps to make such GPUs work, see here for more information. https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html
If that doesn't help, you can use Blender 2.90: https://www.blender.org/download/previous-versions/

Afraid we have to close this report.

Cannot reproduce here ``` **System Information** Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.33.9000 64 Bits Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 465.31 version: 3.0.0 Alpha, branch: master, commit date: 2021-07-14 09:55, hash: `rB5583d517730f` ``` Do you get crash logs? https://docs.blender.org/manual/en/dev/troubleshooting/crash.html#linux The GPU is Terrascale 2, which unfortunately means that this GPU is below the minimum requirements for Blender, so there is no longer support for it. https://www.blender.org/download/requirements/ Installing the latest graphics driver sometimes helps to make such GPUs work, see here for more information. https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html If that doesn't help, you can use Blender 2.90: https://www.blender.org/download/previous-versions/ Afraid we have to close this report.

Anton Raves commented

2021-07-15 07:37:25 +02:00

Using 4e65b1ef6c no crash log was written to /tmp, but I did grab this from the Terminal:

blender.crash.txt

For extra clarity, I am rendering on CPU, so stop whining about the GPU not being supported, please ...

The GPU was supported thanks to https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba

And things were fine in earlier 3.0.0 Alpha versions, I even specified with which Daily Build it started crashing, see above.

Using 4e65b1ef6c no crash log was written to /tmp, but I did grab this from the Terminal: [blender.crash.txt](https://archive.blender.org/developer/F10224666/blender.crash.txt) For extra clarity, I am rendering on CPU, so stop whining about the GPU not being supported, please ... The GPU was supported thanks to [https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba ](https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba) And things were fine in earlier 3.0.0 Alpha versions, I even specified with which Daily Build it started crashing, see above.

Philipp Oeser commented

2021-07-15 10:38:35 +02:00

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Philipp Oeser reopened this issue

2021-07-15 10:38:35 +02:00

Philipp Oeser commented

2021-07-15 10:38:35 +02:00

Added subscriber: @Jeroen-Bakker

Philipp Oeser commented

2021-07-15 10:38:35 +02:00

In #88738#1191373, @Memento wrote:
Using 4e65b1ef6c no crash log was written to /tmp, but I did grab this from the Terminal:

blender.crash.txt

For extra clarity, I am rendering on CPU, so stop whining about the GPU not being supported, please ...

Not whining, but this seems to be a GPU bound error?

Received X11 Error:
	error code:   167
	request code: 150
	minor code:   0
	error text:   GLXBadFBConfig
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.

The GPU was supported thanks to https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba

This somewhat contradicts our requirements https://www.blender.org/download/requirements/:

Since Blender 2.91, Terascale 2 architecture is fully deprecated

Maybe @Jeroen-Bakker wants to comment?

> In #88738#1191373, @Memento wrote: > Using 4e65b1ef6c no crash log was written to /tmp, but I did grab this from the Terminal: > > [blender.crash.txt](https://archive.blender.org/developer/F10224666/blender.crash.txt) > > For extra clarity, I am rendering on CPU, so stop whining about the GPU not being supported, please ... Not whining, but this seems to be a GPU bound error? ``` Received X11 Error: error code: 167 request code: 150 minor code: 0 error text: GLXBadFBConfig [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. ``` > The GPU was supported thanks to [https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba ](https:*developer.blender.org/rB55d14210cccc7a3dae98787200a6dc3649462bba) This somewhat contradicts our requirements https://www.blender.org/download/requirements/: > Since Blender 2.91, Terascale 2 architecture is fully deprecated Maybe @Jeroen-Bakker wants to comment?

Anton Raves commented

2021-07-15 13:53:45 +02:00

What made me report this problem / bug, even though I know that the GPU in that old crate is not a truely supported one, is that I rendered CPU only, then a GPU should not be involved, right...? 🤔

Philipp Oeser commented

2021-07-15 14:01:46 +02:00

In #88738#1191538, @Memento wrote:
What made me report this problem / bug, even though I know that the GPU in that old crate is not a truely supported one, is that I rendered CPU only, then a GPU should not be involved, right...? 🤔

This could also be related to how the renderview is launched (or something else in the UI), so GPU should not be ignored entirely I think.

> In #88738#1191538, @Memento wrote: > What made me report this problem / bug, even though I know that the GPU in that old crate is not a truely supported one, is that I rendered CPU only, then a GPU should not be involved, right...? 🤔 This could also be related to how the renderview is launched (or something else in the UI), so GPU should not be ignored entirely I think.

Anton Raves commented

2021-07-24 21:38:36 +02:00

I think I may have found the cause...

Fedora Workstation 34 by default launches with Wayland and this afternoon out of curiosity I set Fedora to use Xorg upon login... Haven't been able to get Blender on its knees since then, also the #87962 "Toggle Window Fullscreen" on the new Fedora 34 (Wayland mode) makes mouse cursor disappear. problem does not show up when toggling said fullscreen...

Fedora 34 was the first release where they decided on having Wayland set by default and many applications have support for it already, apparently Blender does not yet, which can be logical since NVIDIA does not support Wayland properly either, yet...

I think I may have found the cause... Fedora Workstation 34 by default launches with Wayland and this afternoon out of curiosity I set Fedora to use Xorg upon login... Haven't been able to get Blender on its knees since then, also the #87962 ["Toggle Window Fullscreen" on the new Fedora 34 (Wayland mode) makes mouse cursor disappear. ](https://developer.blender.org/T87962) problem does not show up when toggling said fullscreen... Fedora 34 was the first release where they decided on having Wayland set by default and many applications have support for it already, apparently Blender does not yet, which can be logical since NVIDIA does not support Wayland properly either, yet...

Anton Raves commented

2021-07-24 21:39:21 +02:00

Added subscriber: @christian.rauch

Christian Rauch commented

2021-07-24 21:49:50 +02:00

In #88738#1195857, @Memento wrote:
Fedora 34 was the first release where they decided on having Wayland set by default and many applications have support for it already, apparently Blender does not yet, which can be logical since NVIDIA does not support Wayland properly either, yet...

Fedora uses Wayland by default (on GNOME Shell) since Fedora 25 (https://fedoramagazine.org/whats-new-fedora-25-workstation/). That is for nearly 5 years now.

Using Nvidia is still problematic, with native (Wayland) as well with X11 (via XWayland) applications. I think this is supposed to change with Fedora 35, which will also use Wayland as default for the KDE Plasma session.

Blender builds with Wayland by default now, but it still has to be activated at runtime by setting the BLENDER_WAYLAND environment variable (e.g. BLENDER_WAYLAND= blender).

> In #88738#1195857, @Memento wrote: > Fedora 34 was the first release where they decided on having Wayland set by default and many applications have support for it already, apparently Blender does not yet, which can be logical since NVIDIA does not support Wayland properly either, yet... Fedora uses Wayland by default (on GNOME Shell) since Fedora 25 (https://fedoramagazine.org/whats-new-fedora-25-workstation/). That is for nearly 5 years now. Using Nvidia is still problematic, with native (Wayland) as well with X11 (via XWayland) applications. I think this is supposed to change with Fedora 35, which will also use Wayland as default for the KDE Plasma session. Blender builds with Wayland by default now, but it still has to be activated at runtime by setting the `BLENDER_WAYLAND` environment variable (e.g. `BLENDER_WAYLAND= blender`).

Anton Raves commented

2021-07-24 22:20:37 +02:00

Did so by adding the following to the ~/.bashrc file:

BLENDER_WAYLAND=blender
export BLENDER_WAYLAND

Is that the correct way...? ./blender --version does not mention anything Wayland related. And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing.

Did so by adding the following to the ~/.bashrc file: BLENDER_WAYLAND=blender export BLENDER_WAYLAND Is that the correct way...? ./blender --version does not mention anything Wayland related. And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing.

Christian Rauch commented

2021-07-24 23:30:35 +02:00

In #88738#1195862, @Memento wrote:
Did so by adding the following to the ~/.bashrc file:

BLENDER_WAYLAND=blender
export BLENDER_WAYLAND

This is not exactly what I meant, but it will still have the same effect. You are setting the environment variable BLENDER_WAYLAND to the value "blender".

There is a space between BLENDER_WAYLAND= and blender in what I wrote above. It does not matter to what value you set BLENDER_WAYLAND, it can even be empty as in the case I mentioned above. It only matters that it is defined (i.e. getenv("BLENDER_WAYLAND") does not return NULL).

If you do export BLENDER_WAYLAND=, it will define BLENDER_WAYLAND to be empty. The effect will be the same as if you set an arbitrary value, e.g. export BLENDER_WAYLAND=ON.

The command BLENDER_WAYLAND= blender will set the environment variable BLENDER_WAYLAND to be empty (but defined) and call the blender executable in a single line.

Is that the correct way...? ./blender --version does not mention anything Wayland related.

Well, blender --version is not supposed to say anything about Wayland. It also does not say anything about X11. If you run Blender with BLENDER_WAYLAND in a GNOME Shell Wayland session, you will notice that it will have decorations missing. If still in doubt, you can identify Wayland clients in a GNOME Shell session via "looking glass": https://unix.stackexchange.com/a/435159.

And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing.

In this issue, you mentioned yourself that it also appears for other clients. There is nothing to be done within Blender.

> In #88738#1195862, @Memento wrote: > Did so by adding the following to the ~/.bashrc file: > > BLENDER_WAYLAND=blender > export BLENDER_WAYLAND This is not exactly what I meant, but it will still have the same effect. You are setting the environment variable `BLENDER_WAYLAND` to the value `"blender"`. There is a space between `BLENDER_WAYLAND=` and `blender` in what I wrote above. It does not matter to what value you set `BLENDER_WAYLAND`, it can even be empty as in the case I mentioned above. It only matters that it is defined (i.e. `getenv("BLENDER_WAYLAND")` does not return `NULL`). If you do `export BLENDER_WAYLAND=`, it will define `BLENDER_WAYLAND` to be empty. The effect will be the same as if you set an arbitrary value, e.g. `export BLENDER_WAYLAND=ON`. The command `BLENDER_WAYLAND= blender` will set the environment variable `BLENDER_WAYLAND` to be empty (but defined) and call the `blender` executable in a single line. > Is that the correct way...? ./blender --version does not mention anything Wayland related. Well, `blender --version` is not supposed to say anything about Wayland. It also does not say anything about X11. If you run Blender with `BLENDER_WAYLAND` in a GNOME Shell Wayland session, you will notice that it will have decorations missing. If still in doubt, you can identify Wayland clients in a GNOME Shell session via "looking glass": https://unix.stackexchange.com/a/435159. > And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing. In this issue, you mentioned yourself that it also appears for other clients. There is nothing to be done within Blender.

Anton Raves commented

2021-07-25 07:34:35 +02:00

And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing.

In this issue, you mentioned yourself that it also appears for other clients. There is nothing to be done within Blender.

Out of posterity I tried, one can hope, can one not...? 😉

> > And the #87962 toggle can still not be done, the rest I could try and do without Blender crashing. > In this issue, you mentioned yourself that it also appears for other clients. There is nothing to be done within Blender. Out of posterity I tried, one can hope, can one not...? 😉

Philipp Oeser commented

2023-02-14 12:46:53 +01:00

Going over old issues, sorry this has been lying around (and this one does not have a module assigned).

Before sending this into triaging again, I would like to know though if with newer Fedora/blender versions, is this still a problem?

Going over old issues, sorry this has been lying around (and this one does not have a module assigned). Before sending this into triaging again, I would like to know though if with newer Fedora/blender versions, is this still a problem?

Philipp Oeser added

Status

Needs Information from User

and removed

Status

Needs Info from Developers

labels 2023-02-14 12:47:02 +01:00

Anton Raves commented

2023-02-14 13:04:35 +01:00

Currently using Fedora 37 and an Alpha version 3.5.0 of Blender and can't get things to their proverbial knees now... Lots of things have changed... Cycles X and more... As far as I am concerned this Task can be closed...