Crash closing file browsers with AMD GPUs #76113

New Issue

Lucas Newcomb · 2020-04-26T03:55:43+02:00

Lucas Newcomb commented

2020-04-26 03:55:43 +02:00

System Information

Windows 10 64-bits
AMD Mobility Radeon HD 5800 Series
AMD Radeon HD 5700 Series
AMD Radeon HD 7310 Graphics
AMD Radeon HD 8210

Linux
AMD Radeon RX 5700 XT
AMD Ryzen 5 2500U / Vega 8 graphics
Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6

Blender Version
Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-04-25 17:40, hash: f418eddf8e
Worked: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: 77d23b0bd7

Short description of error
Blender crashes upon closing the file browser
blender_debug_output.txt
system-info.txt

A similar problem is also seen on Linux:
blender.crash.txt
blender.crash.txt
blender.crash.txt

Exact steps for others to reproduce the error

Open the file browser.
Wait at least 5 seconds.
Close the file browser.

**System Information** |**Windows 10 64-bits** | -- | |AMD Mobility Radeon HD 5800 Series | 4.5.13399 Core Profile Context 15.201.1151.1008 |AMD Radeon HD 5700 Series | 4.5.13417 Core Profile Context 15.301.1901.0 |AMD Radeon HD 7310 Graphics | 4.5.13399 Core Profile Context 15.200.1062.1004 |AMD Radeon HD 8210 | 4.5.13399 Core Profile Context 15.200.1065.0 |**Linux** | -- | |AMD Radeon RX 5700 XT |AMD Ryzen 5 2500U / Vega 8 graphics |Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6 **Blender Version** Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-04-25 17:40, hash: `f418eddf8e` Worked: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `77d23b0bd7` **Short description of error** Blender crashes upon closing the file browser [blender_debug_output.txt](https://archive.blender.org/developer/F8495388/blender_debug_output.txt) [system-info.txt](https://archive.blender.org/developer/F8495389/system-info.txt) A similar problem is also seen on Linux: [blender.crash.txt](https://archive.blender.org/developer/F8499308/blender.crash.txt) [blender.crash.txt](https://archive.blender.org/developer/F8504083/blender.crash.txt) [blender.crash.txt](https://archive.blender.org/developer/F8505477/blender.crash.txt) **Exact steps for others to reproduce the error** - Open the file browser. - Wait at least 5 seconds. - Close the file browser.

Lucas Newcomb commented

2020-04-26 03:55:43 +02:00

Added subscriber: @Tony_PJs

blender-admin commented

2020-04-26 03:55:43 +02:00

#76640 was marked as duplicate of this issue

blender-admin commented

2020-04-26 03:55:43 +02:00

#76307 was marked as duplicate of this issue

blender-admin commented

2020-04-26 03:55:43 +02:00

#76193 was marked as duplicate of this issue

blender-admin commented

2020-04-26 03:55:43 +02:00

#76142 was marked as duplicate of this issue

blender-admin commented

2020-04-26 03:55:43 +02:00

#76252 was marked as duplicate of this issue

blender-admin commented

2020-04-26 03:55:43 +02:00

#76186 was marked as duplicate of this issue

Vas commented

2020-04-26 06:54:29 +02:00

Added subscriber: @Alumx

Vas commented

2020-04-26 06:54:29 +02:00

Cannot replicate


Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19
2.83 (sub 15), branch: master, commit date: 2020-04-25 17:40, hash: `rBf418eddf8e1c`

Cannot replicate ``` Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19 2.83 (sub 15), branch: master, commit date: 2020-04-25 17:40, hash: `rBf418eddf8e1c` ```

Ankit Meel commented

2020-04-26 07:56:22 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-04-26 07:56:22 +02:00

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

Ankit Meel commented

2020-04-26 07:56:22 +02:00

Retry after moving the C:\Users\Lucas\AppData\Roaming\Blender Foundation folder somewhere else.

Retry after moving the C:\\Users\\Lucas\\AppData\\Roaming\\Blender Foundation folder somewhere else.

Lucas Newcomb commented

2020-04-26 08:38:51 +02:00

Problem persists after folder was moved. Also tried to run Blender is administrator with no luck.

Ankit Meel commented

2020-04-26 08:50:07 +02:00

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

Ankit Meel commented

2020-04-26 08:50:07 +02:00

#75657 (Blender 2.82 crashes on Save As and export) a bit similar report

Lucas Newcomb commented

2020-04-26 08:56:14 +02:00

Attempted to replicate on another machine and it worked just fine, could be an issue with the hardware/software on the first machine as it is older than the other one.

Germano Cavalcante commented

2020-04-28 13:46:41 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-04-28 13:46:41 +02:00

Strange, the blender_debug_output.txt provided does not show any information about the crash.

Strange, the `blender_debug_output.txt` provided does not show any information about the crash.

Brecht Van Lommel commented

2020-04-28 16:56:13 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-04-28 16:56:13 +02:00

This graphics card is below Blender minimum requirements, and so is unsupported. Driver version 15.201.1151.1008 is also from 2015 and quite old.

Installing the "Crimson Edition Beta" driver version may help.
https://www.amd.com/en/support/graphics/amd-radeon-hd/ati-radeon-hd-5000-series/ati-radeon-hd-5770

This graphics card is below Blender minimum requirements, and so is unsupported. Driver version 15.201.1151.1008 is also from 2015 and quite old. Installing the "Crimson Edition Beta" driver version may help. https://www.amd.com/en/support/graphics/amd-radeon-hd/ati-radeon-hd-5000-series/ati-radeon-hd-5770

Brecht Van Lommel commented

2020-04-28 16:56:33 +02:00

Added subscriber: @Nelfie

Brecht Van Lommel changed title from ~~2.83.15 Crashing on file browser close~~ to Crash closing file browsers with AMD Radeon HD 5xxx and driver version 15.x

2020-04-28 17:00:30 +02:00

Ray molenkamp commented

2020-04-28 17:04:12 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2020-04-28 17:04:12 +02:00

not sure if it's this exact issue but when you open the file browser it shows an empty list for a short moment, when it opens in a substantially large folder, it sometimes takes a few seconds for the files to get listed, if during that time you close the window blender will crash, issue is, second time you try to catch it with the debugger, all fileio is cached and the crash becomes hard to trigger. I know this exists, but a stack trace has yet been hard to come by.

Ankit Meel commented

2020-04-28 17:08:38 +02:00

all fileio is cached and the crash becomes hard to trigger.

That should be flushed after a restart ?
Or in the safe mode like concept: https://en.wikipedia.org/wiki/Safe_mode#macOS

> all fileio is cached and the crash becomes hard to trigger. That should be flushed after a restart ? Or in the safe mode like concept: https://en.wikipedia.org/wiki/Safe_mode#macOS

Richard Antalik commented

2020-04-28 17:44:57 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-04-28 17:44:57 +02:00

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

Richard Antalik commented

2020-04-28 17:44:57 +02:00

There is no mention of crash in blender_debug_output.txt so I would like to hear if updating driver will help.

Otherwise without stack trace especially on unsupported GPU I would normally close report. So if you want to investigate this regardless, leave a comment.

There is no mention of crash in `blender_debug_output.txt` so I would like to hear if updating driver will help. Otherwise without stack trace especially on unsupported GPU I would normally close report. So if you want to investigate this regardless, leave a comment.

Ankit Meel commented

2020-04-30 10:14:15 +02:00

Added subscriber: @Dillen

Richard Antalik commented

2020-04-30 18:28:35 +02:00

Added subscriber: @kissmecomix

Germano Cavalcante commented

2020-05-01 13:52:23 +02:00

Added subscribers: @dustinwilson, @Nekto_Roboto, @EricChirnside

Ankit Meel commented

2020-05-01 15:00:30 +02:00

Otherwise without stack trace especially on unsupported GPU ..

There are three linux logs in #76193.

> Otherwise without stack trace especially on unsupported GPU .. There are three linux logs in #76193.

Brecht Van Lommel changed title from ~~Crash closing file browsers with AMD Radeon HD 5xxx and driver version 15.x~~ to Crash closing file browsers with AMD GPUs

2020-05-01 21:48:20 +02:00

Germano Cavalcante commented

2020-05-01 23:52:40 +02:00

I was unable to reproduce the crash, but I had a freeze testing on Windows + AMD Radeon HD 7570M.
The problem is very deep in the driver and apparently involves multithread.
I couldn't find another workaround other than changing GL_DYNAMIC_DRAW to GL_STATIC_DRAW:

diff --git a/source/blender/gpu/intern/gpu_immediate.c b/source/blender/gpu/intern/gpu_immediate.c
index 5a5dfb3e1e8..f60308365a6 100644
--- a/source/blender/gpu/intern/gpu_immediate.c
+++ b/source/blender/gpu/intern/gpu_immediate.c
@@ -268,7 +268,7 @@ void immBegin(GPUPrimType prim_type, uint vertex_len)
   else {
     /* orphan this buffer & start with a fresh one */
     /* this method works on all platforms, old & new */
-    glBufferData(GL_ARRAY_BUFFER, active_buffer->buffer_size, NULL, GL_DYNAMIC_DRAW);
+    glBufferData(GL_ARRAY_BUFFER, active_buffer->buffer_size, NULL, GL_STATIC_DRAW);
 
     active_buffer->buffer_offset = 0;
   }

I also don't know if that would solve the reported cases.

I was unable to reproduce the crash, but I had a freeze testing on `Windows` + `AMD Radeon HD 7570M`. The problem is very deep in the driver and apparently involves multithread. I couldn't find another workaround other than changing `GL_DYNAMIC_DRAW` to `GL_STATIC_DRAW`: ``` diff --git a/source/blender/gpu/intern/gpu_immediate.c b/source/blender/gpu/intern/gpu_immediate.c index 5a5dfb3e1e8..f60308365a6 100644 --- a/source/blender/gpu/intern/gpu_immediate.c +++ b/source/blender/gpu/intern/gpu_immediate.c @@ -268,7 +268,7 @@ void immBegin(GPUPrimType prim_type, uint vertex_len) else { /* orphan this buffer & start with a fresh one */ /* this method works on all platforms, old & new */ - glBufferData(GL_ARRAY_BUFFER, active_buffer->buffer_size, NULL, GL_DYNAMIC_DRAW); + glBufferData(GL_ARRAY_BUFFER, active_buffer->buffer_size, NULL, GL_STATIC_DRAW); active_buffer->buffer_offset = 0; } ``` I also don't know if that would solve the reported cases.

Rod Jenkins commented

2020-05-02 00:45:21 +02:00

May I ask if you use an HP model? maybe it has something to do with things

Ankit Meel commented

2020-05-02 09:54:17 +02:00

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

Ankit Meel commented

2020-05-02 09:54:17 +02:00

(status change) (added UI for window management)

Ankit Meel commented

2020-05-02 11:54:26 +02:00

Added subscriber: @Memento

Brecht Van Lommel commented

2020-05-02 12:08:11 +02:00

@mano-wii, did you check if the freeze you found is due to the change in 5d9d246851 or other commit? If it's related to a specific commit it could help us understand the problem.

@mano-wii, did you check if the freeze you found is due to the change in 5d9d246851 or other commit? If it's related to a specific commit it could help us understand the problem.

Germano Cavalcante commented

2020-05-02 13:24:21 +02:00

@kissmecomix, tested on a DELL

@brecht, yes i checked. That commit introduced the issue.
This's because glBufferData is called much more often than before.

@kissmecomix, tested on a DELL @brecht, yes i checked. That commit introduced the issue. This's because glBufferData is called much more often than before.

Germano Cavalcante commented

2020-05-02 15:28:47 +02:00

I submitted a possible fix to master.
Please test as soon as the build is available in https://builder.blender.org/download/

I submitted a possible fix to master. Please test as soon as the build is available in https://builder.blender.org/download/

Eric commented

2020-05-02 19:47:41 +02:00

In #76113#922395, @mano-wii wrote:
I submitted a possible fix to master.
Please test as soon as the build is available in https://builder.blender.org/download/

Can confirm that this nightly fixed my problem from https://developer.blender.org/T76193

version: 2.83 (sub 15), branch: master, commit date: 2020-05-01 21:42, hash: bba11c68c4, type: Release
build date: 2020-05-01, 23:09:48

Manjaro Linux
Huawei Matebook D 14 AMD
AMD Ryzen 5 2500U / Vega 8 graphics

Thanks!

Actually, scratch that. It worked the once and then crashed again but I just realized the new build wasn't available yet anyway. Will try again when it is. Sorry for the confusion.

> In #76113#922395, @mano-wii wrote: > I submitted a possible fix to master. > Please test as soon as the build is available in https://builder.blender.org/download/ > Can confirm that this nightly fixed my problem from https://developer.blender.org/T76193 > > version: 2.83 (sub 15), branch: master, commit date: 2020-05-01 21:42, hash: bba11c68c404, type: Release > build date: 2020-05-01, 23:09:48 > > Manjaro Linux > Huawei Matebook D 14 AMD > AMD Ryzen 5 2500U / Vega 8 graphics > > Thanks! Actually, scratch that. It worked the once and then crashed again but I just realized the new build wasn't available yet anyway. Will try again when it is. Sorry for the confusion.

Eric commented

2020-05-03 05:23:01 +02:00

This comment was removed by @EricChirnside

*This comment was removed by @EricChirnside*

Anton Raves commented

2020-05-03 07:54:06 +02:00

Continues to crash with version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: 1623fdb3bc

System Information
Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5

Continues to crash with version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: `1623fdb3bc` **System Information** Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5

Sergey Sidun commented

2020-05-03 09:32:12 +02:00

Confirm, continues to crash with new build.
System Information
Operating system: Linux-5.6.8-arch1-1-x86_64-with-arch-Arch-Linux 64 Bits
Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6

Blender Version
Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: 1623fdb3bc

Confirm, continues to crash with new build. **System Information** Operating system: Linux-5.6.8-arch1-1-x86_64-with-arch-Arch-Linux 64 Bits Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6 **Blender Version** Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: `1623fdb3bc`

Ankit Meel commented

2020-05-03 09:51:41 +02:00

Added subscriber: @Bearcat

Ankit Meel commented

2020-05-03 09:51:41 +02:00

@Nekto_Roboto @Memento @EricChirnside test 2.90 with hash > 7df51ca
1623fd doesn't even have the fix.
2.90: 6408cd is now available at https://builder.blender.org/download/
Test that.

![image.png](https://archive.blender.org/developer/F8508873/image.png) @Nekto_Roboto @Memento @EricChirnside test 2.90 with hash > 7df51ca 1623fd doesn't even have the fix. 2.90: 6408cd is now available at https://builder.blender.org/download/ Test that.

Anton Raves commented

2020-05-03 10:39:14 +02:00

System Information
Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5

Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-02 16:01, hash: 6408cd00c5

Unfortunately crashes just as well...

**System Information** Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5 **Blender Version** Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-02 16:01, hash: `6408cd00c5` Unfortunately crashes just as well...

dark999 commented

2020-05-03 15:11:36 +02:00

Added subscriber: @dark999

dark999 commented

2020-05-03 15:11:37 +02:00

@Memento you have one not meeting minimum requirement GPU (Radeon HD 57xx/terascale2) with not supported GPU driver (Mesa), Blender support only (Amd and Nvidia propietary linux driver

@Memento you have one not meeting minimum requirement GPU (Radeon HD 57xx/terascale2) with not supported GPU driver (Mesa), Blender support only (Amd and Nvidia propietary linux driver ![image.png](https://archive.blender.org/developer/F8509271/image.png)

Anton Raves commented

2020-05-03 15:15:48 +02:00

Worked fine before I went from Fedora 31 to Fedora 32... And the crashes only occur when closing an extra Blender window, like Preferences or the File Browser, nothing exciting there...

Sergey Sidun commented

2020-05-03 16:08:00 +02:00

System Information
Operating system: Linux-5.6.8-arch1-1-x86_64-with-arch-Arch-Linux 64 Bits
Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6

Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-02 16:01, hash: 6408cd00c5

The problem still persists on new build...crashes when working with file browser

I also wanted to mention that problem occurred after some system updates, maybe one week ago

**System Information** Operating system: Linux-5.6.8-arch1-1-x86_64-with-arch-Arch-Linux 64 Bits Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.8-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6 **Blender Version** Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-02 16:01, hash: `6408cd00c5` The problem still persists on new build...crashes when working with file browser I also wanted to mention that problem occurred after some system updates, maybe one week ago

dark999 commented

2020-05-03 16:57:28 +02:00

@Nekto_Roboto check if you meet ALL Blender requirement www.blender.org/download/requirements/

Eric commented

2020-05-04 05:37:10 +02:00

In #76113#923202, @dark999 wrote:
@Nekto_Roboto check if you meet ALL Blender requirement www.blender.org/download/requirements/

Well, I have a supported GPU and can confirm that the crash continues in the latest nightly of 2.83.

version: 2.83 (sub 15), branch: master, commit date: 2020-05-03 18:42, hash: 331bf04fad, type: Release
build date: 2020-05-03, 22:59:36
platform: Linux

Basically 2.80 is the last version that doesn't crash on my current setup for this issue, so pre- new file browser, I guess. I feel like I was using 2.81 without issue at one point, but I'm not entirely sure how extensively I used that version at the time.

I just installed the latest Manjaro updates, which included a new version of Mesa, but no luck.

OpenGL renderer string: AMD RAVEN (DRM 3.36.0, 5.5.19-1-MANJARO, LLVM 10.0.0)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.6

And by the way @dark999, Mesa drivers ARE the driver stack recommended by AMD for all their non-Pro consumer products. Their own Software for Linux site says so. https://www.amd.com/en/support/kb/faq/amdgpu-installation. Unlike Nvidia, they actually do contribute to Mesa.

Also, sorry @ankitm, I didn't see your earlier tag. I just tried with the following build and encountered the same crash. If you need any particular logs, let me know.

version: 2.90 (sub 0), branch: master, commit date: 2020-05-03 22:25, hash: 33bdd91fb8, type: Release
build date: 2020-05-03, 23:06:18
platform: Linux

> In #76113#923202, @dark999 wrote: > @Nekto_Roboto check if you meet ALL Blender requirement www.blender.org/download/requirements/ Well, I have a supported GPU and can confirm that the crash continues in the latest nightly of 2.83. version: 2.83 (sub 15), branch: master, commit date: 2020-05-03 18:42, hash: 331bf04fad93, type: Release build date: 2020-05-03, 22:59:36 platform: Linux Basically 2.80 is the last version that doesn't crash on my current setup for this issue, so pre- new file browser, I guess. I feel like I was using 2.81 without issue at one point, but I'm not entirely sure how extensively I used that version at the time. I just installed the latest Manjaro updates, which included a new version of Mesa, but no luck. OpenGL renderer string: AMD RAVEN (DRM 3.36.0, 5.5.19-1-MANJARO, LLVM 10.0.0) OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.6 And by the way @dark999, Mesa drivers ARE the driver stack recommended by AMD for all their non-Pro consumer products. Their own Software for Linux site says so. https://www.amd.com/en/support/kb/faq/amdgpu-installation. Unlike Nvidia, they actually do contribute to Mesa. Also, sorry @ankitm, I didn't see your earlier tag. I just tried with the following build and encountered the same crash. If you need any particular logs, let me know. version: 2.90 (sub 0), branch: master, commit date: 2020-05-03 22:25, hash: 33bdd91fb825, type: Release build date: 2020-05-03, 23:06:18 platform: Linux

Brecht Van Lommel commented

2020-05-04 10:49:32 +02:00

In #76113#922371, @mano-wii wrote:
@brecht, yes i checked. That commit introduced the issue.
This's because glBufferData is called much more often than before.

That fix was for a performance issue on Intel cards. The simple & safe solution would be to only use the two buffers on Intel cards and leave the old code for AMD.

> In #76113#922371, @mano-wii wrote: > @brecht, yes i checked. That commit introduced the issue. > This's because glBufferData is called much more often than before. That fix was for a performance issue on Intel cards. The simple & safe solution would be to only use the two buffers on Intel cards and leave the old code for AMD.

Brecht Van Lommel commented

2020-05-06 23:57:07 +02:00

I believe this is supposed to be fixed by 37182c3.

Can anyone confirm if this bug still exists in the latest 2.83 build?
https://builder.blender.org/download/

I believe this is supposed to be fixed by 37182c3. Can anyone confirm if this bug still exists in the latest 2.83 build? https://builder.blender.org/download/

Eric commented

2020-05-07 01:56:10 +02:00

@brecht It's still happening in this version:

version: 2.83 (sub 15), branch: master, commit date: 2020-05-06 16:18, hash: 9605c26166, type: Release
build date: 2020-05-06, 23:02:36

@brecht It's still happening in this version: version: 2.83 (sub 15), branch: master, commit date: 2020-05-06 16:18, hash: 9605c2616696, type: Release build date: 2020-05-06, 23:02:36

Anton Raves commented

2020-05-07 05:59:52 +02:00

I concur with Eric, still crashing with hash 9605c2616696 here

I concur with Eric, still crashing with hash `9605c2616696` here

Dillen Bata commented

2020-05-07 13:31:55 +02:00

I can confirm as of 2.83 #9605c2616696 and 2.90 #05da8132d8f7 opening filebrowser or preferences in new window and closing is fixed. Thank you for your hard work.

Brecht Van Lommel commented

2020-05-07 13:41:04 +02:00

Thanks, so perhaps it's fixed on Windows but not on Linux.

Ankit Meel commented

2020-05-07 13:42:40 +02:00

Removed subscriber: @Bearcat

Sergey Sidun commented

2020-05-07 13:58:31 +02:00

Version: 2.90 (sub 0), branch: master, commit date: 2020-05-06 23:00, hash: 05da8132d8
Unfortunately still crashing on arch linux

Version: 2.90 (sub 0), branch: master, commit date: 2020-05-06 23:00, hash: `05da8132d8` Unfortunately still crashing on arch linux

Dustin Wilson commented

2020-05-07 17:59:30 +02:00

I am still having the same crash when closing the file dialog for selecting an image texture on Manjaro on the latest alpha build as well.

Eric commented

2020-05-08 06:28:00 +02:00

Wait, is this only cropping up on Manjaro/Arch Linux systems at this point? This is probably totally unrelated but I recently helped troubleshoot a problem in another project (the Qodot plugin for Godot Engine) which only affected Arch and Manjaro, maybe because they're rolling releases and tend to have more recent libraries installed. The developer reported it had something to do with initializing a dynamic memory check and talked about it in a blog post after fixing it:

Merciful as this was, it was also puzzling- the program was segfaulting on an innocuous comment = false; line designed to initialize a global boolean variable declared inside the map parser's C file.

No dynamic memory allocation or incorrect deallocation even had the chance to happen at this point in the program, and file-scope globals are supposed to be safe from the dangers of bad pointer management.

In the end, the fix turned out to be marking all non-struct file-scope parse state variables as static. Unfortunately I'm not sure exactly why this is- my best informed guess is that it ensures those variables are initialized before being used in accordance with the OS and hardware-specific C implementation, but that sort of implementation discrepancy seems difficult to believe given C's long tenure.

It's also possible that something related to Godot's heavy use of threads was having an effect on the plugin's code execution relative to the variables' initialization, but it seems more likely that I was leaning on undefined behavior that happens to be handled nicely on all other configurations.

Like I said, probably unrelated, but it seems most (all?) of the Linux users reporting this here and on the issue I got merged in from are on Arch or Manjaro as well, so I thought I'd mention it. shrug emoji

Wait, is this only cropping up on Manjaro/Arch Linux systems at this point? This is probably totally unrelated but I recently helped troubleshoot a problem in another project (the Qodot plugin for Godot Engine) which only affected Arch and Manjaro, maybe because they're rolling releases and tend to have more recent libraries installed. The developer reported it had something to do with initializing a dynamic memory check and talked about it in a blog post after fixing it: > Merciful as this was, it was also puzzling- the program was segfaulting on an innocuous comment = false; line designed to initialize a global boolean variable declared inside the map parser's C file. > > No dynamic memory allocation or incorrect deallocation even had the chance to happen at this point in the program, and file-scope globals are supposed to be safe from the dangers of bad pointer management. > > In the end, the fix turned out to be marking all non-struct file-scope parse state variables as static. Unfortunately I'm not sure exactly why this is- my best informed guess is that it ensures those variables are initialized before being used in accordance with the OS and hardware-specific C implementation, but that sort of implementation discrepancy seems difficult to believe given C's long tenure. > > It's also possible that something related to Godot's heavy use of threads was having an effect on the plugin's code execution relative to the variables' initialization, but it seems more likely that I was leaning on undefined behavior that happens to be handled nicely on all other configurations. Like I said, probably unrelated, but it seems most (all?) of the Linux users reporting this here and on the issue I got merged in from are on Arch or Manjaro as well, so I thought I'd mention it. *shrug emoji*

Anton Raves commented

2020-05-08 08:13:37 +02:00

Fedora 32 here... Semi rolling release...

Vas commented

2020-05-08 15:47:44 +02:00

Removed subscriber: @Alumx

Germano Cavalcante commented

2020-05-08 20:51:49 +02:00

I have a setup a little bit similar here, but I can't reproduce the problem:
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: AMD Radeon HD 7570M ATI Technologies Inc. 4.5.13399 Core Profile Context 0

I have a setup a little bit similar here, but I can't reproduce the problem: Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: AMD Radeon HD 7570M ATI Technologies Inc. 4.5.13399 Core Profile Context 0

Brecht Van Lommel commented

2020-05-08 20:53:21 +02:00

@mano-wii from the comments this seems to be a Linux only issue, so testing on Windows would not work.

Dustin Wilson commented

2020-05-10 17:08:10 +02:00

In addition to what I outlined about my issue in #76193 I've been tinkering around with Blender to see if I can discover anything about the crash myself. I've discovered I can successfully apply a texture by using the material properties, clicking on the circle next to Base Color, applying an image texture, and opening an image. However, if I use nodes via the Shading tab like I did in my original report I get the crash when opening the texture image.

Josh Luchs commented

2020-05-10 21:27:36 +02:00

Added subscriber: @jshlxx

Sebastian Parborg commented

2020-05-11 12:02:06 +02:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2020-05-11 12:02:06 +02:00

Just a heads up. I do remember having issues with this. (So random crashes when closing this file browser).
But I can't reproduce this anymore it seems.

I'm running Gentoo and using Mesa 20.2.0 (git master version, AMD RX 5700 XT).

Just a heads up. I do remember having issues with this. (So random crashes when closing this file browser). But I can't reproduce this anymore it seems. I'm running Gentoo and using Mesa 20.2.0 (git master version, AMD RX 5700 XT).

Richard Antalik commented

2020-05-11 12:09:54 +02:00

Added subscriber: @MartinLouette

Joshua Anderson commented

2020-05-11 19:42:39 +02:00

Added subscriber: @andersmmg

Joshua Anderson commented

2020-05-11 19:42:39 +02:00

I'm using Manjaro, and I recently started getting a buffer overflow when opening most image textures from the shader editor, and Blender crashes when I load fonts as well. The crash log doesn't seem to have any useful information.

Clément Foucault commented

2020-05-11 19:57:25 +02:00

Added subscriber: @fclem

Clément Foucault self-assigned this 2020-05-11 19:57:25 +02:00

Clément Foucault commented

2020-05-11 19:57:25 +02:00

I can reproduce the bug with AMD + Mesa drivers when selecting an image to open.

Looking into it now.

I can reproduce the bug with AMD + Mesa drivers when selecting an image to open. Looking into it now.

Josh Luchs commented

2020-05-11 20:20:20 +02:00

Removed subscriber: @jshlxx

Clément Foucault commented

2020-05-11 20:48:17 +02:00

The crash I can reproduce is NOT comming from 5d9d246851 and I can reproduce the crash up to 2.81 when we introduce the popup window for file open. So it is not really coming from us.

I'll be commenting the file explorer code until I find the culprit area of the code.

The crash I can reproduce is NOT comming from 5d9d246851 and I can reproduce the crash up to 2.81 when we introduce the popup window for file open. So it is not really coming from us. I'll be commenting the file explorer code until I find the culprit area of the code.

Clément Foucault commented

2020-05-12 02:51:17 +02:00

The crash seems to come from the closing of the window and not from the drawing happening inside it. But it never happens with other tmp window (like driver or render).

I tried to see if something was out of place in wm_handler_fileselect_do but nothing is standing out. Note that the error still trigger if closing the window using the OS button (GHOST_kEventWindowClose).

Only avoiding the closing of the windows avoid the crash.

It has nothing to do with child window, it happens even when forcing normal window.

The crash can happen in different circumstances:

Opening fresh factory blender > file open > close new window > WITHOUT updating any view3D switch to shading tab > Crash
Opening fresh factory blender > Shading Tab > add texture node > texture open > confirm choice > Crash (already reported)
Opening fresh factory blender > Shading Tab > add texture node > texture open > close new window > texture open again > Crash

The crash don't seem to be related to EEVEE as it also happens even if shading workspace use a solid viewport.

BUT, I found that it is related to the UV image editor area that is present in the shading workspace. The crash also happens in the Texturing and UV editing workspace.

I still not sure where it comes from as removing all the drawing inside the UV image editor does not solve the issue.

The crash seems to come from the closing of the window and not from the drawing happening inside it. But it never happens with other tmp window (like driver or render). I tried to see if something was out of place in `wm_handler_fileselect_do` but nothing is standing out. Note that the error still trigger if closing the window using the OS button (`GHOST_kEventWindowClose`). Only avoiding the closing of the windows avoid the crash. It has nothing to do with child window, it happens even when forcing normal window. The crash can happen in different circumstances: - Opening fresh factory blender > file open > close new window > WITHOUT updating any view3D switch to shading tab > Crash - Opening fresh factory blender > Shading Tab > add texture node > texture open > confirm choice > Crash (already reported) - Opening fresh factory blender > Shading Tab > add texture node > texture open > close new window > texture open again > Crash The crash don't seem to be related to EEVEE as it also happens even if shading workspace use a solid viewport. BUT, I found that it is related to the UV image editor area that is present in the shading workspace. The crash also happens in the Texturing and UV editing workspace. I still not sure where it comes from as removing all the drawing inside the UV image editor does not solve the issue.

Anton Raves commented

2020-05-12 07:52:31 +02:00

Clément,

It also happens with:

Opening fresh factory blender > preferences > close preferences window
Opening fresh factory blender > render the default scene > close render window with ESC-key or the window close button

However, switching to the main Blender window again will not cause a crash, just when closing any additional window it will, leaving the additional window in the background Blender continues to remain operable.

Clément, It also happens with: - Opening fresh factory blender > preferences > close preferences window - Opening fresh factory blender > render the default scene > close render window with ESC-key or the window close button However, switching to the main Blender window again will not cause a crash, just when closing any additional window it will, leaving the additional window in the background Blender continues to remain operable.

Jeroen Bakker commented

2020-05-12 15:42:47 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-05-12 15:42:47 +02:00

I wasn't able to reproduce it on a blender 2.83 release build on the next system. It uses Mesa 19.2.8

system-info.txt

Which should be similar as what @fclem has.

I wasn't able to reproduce it on a blender 2.83 release build on the next system. It uses Mesa 19.2.8 [system-info.txt](https://archive.blender.org/developer/F8530761/system-info.txt) Which should be similar as what @fclem has.

blender-admin commented

2020-05-12 17:56:32 +02:00

This issue was referenced by ac1a6565df

This issue was referenced by ac1a6565dfe7f2e784df106e219f2b9444f34ca9

Clément Foucault commented

2020-05-12 18:00:29 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Clément Foucault closed this issue

2020-05-12 18:00:29 +02:00

Anton Raves commented

2020-05-13 06:44:26 +02:00

Blender 2.90 Alpha f9d0f59bed4d works now, did the patch make it into Blender 2.83 Beta yet? For the buildbot version 50ef801a79b5 still crashes unfortunately...

Edit: Unfortunately Blender 2.90 Alpha f9d0f59bed4d also continues to crash, it just took longer before it did so.

Opening fresh factory blender > preferences > close preferences window
Opening fresh factory blender > render the default scene > close default scene with ESC-key or the window close button

Blender 2.90 Alpha `f9d0f59bed4d` works now, did the patch make it into Blender 2.83 Beta yet? For the buildbot version `50ef801a79b5` still crashes unfortunately... Edit: Unfortunately Blender 2.90 Alpha `f9d0f59bed4d` also continues to crash, it just took longer before it did so. - Opening fresh factory blender > preferences > close preferences window - Opening fresh factory blender > render the default scene > close default scene with ESC-key or the window close button

Clément Foucault commented

2020-05-13 15:34:51 +02:00

@Memento At this point I would turn to Mesa to fix the driver. I cannot reproduce the crash even with the same version of the lib. This might be because of a specific driver path for your GPU family. But given we don't support your GPU familly (terascale2) anymore, I can't spend more time on this.

Dustin Wilson commented

2020-05-13 15:42:29 +02:00

I was able to test this out today, and I am no longer getting the crash on my system in 2.83. Thanks a bunch!

Joshua Anderson commented

2020-05-13 18:37:25 +02:00

Same, it seems fixed in 2.83, for both loading image textures and fonts!

Eric commented

2020-05-14 08:02:20 +02:00

Well it's better than it was as it no longer happens instantly after opening and closing the file browser just once, but I can unfortunately still get it to crash reliably.

Open Blender, switch to Shading tab. Create image texture node and load any image, connect to Metallic input. Create second image texture node and connect to Base Color input. Open file browser from this node and then close it. Open and close it around 3-6 more times. It reliably crashes for me every single time I follow these steps.

Blender 2.83 (sub 16), Commit date: 2020-05-13 20:48, Hash 71298a1da9

blender_2_83_sub_16_2020-05-13_error.log

blender_2_83_sub_16_2020-05-13_blender.crash.txt

AMD Ryzen 5 2500U / Vega 8

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD RAVEN (DRM 3.35.0, 5.4.39-1-MANJARO, LLVM 10.0.0) (0x15dd)
    Version: 20.0.6

I0514 01:37:46.244590  4431 blender_python.cpp:191] Debug flags initialized to:
CPU flags:
  AVX2       : True
  AVX        : True
  SSE4.1     : True
  SSE3       : True
  SSE2       : True
  BVH layout : BVH8
  Split      : False
CUDA flags:
  Adaptive Compile : False
OptiX flags:
  CUDA streams : 1
OpenCL flags:
  Device type    : ALL
  Debug          : False
  Memory limit   : 0
Segmentation fault (core dumped)

Well it's better than it was as it no longer happens instantly after opening and closing the file browser just once, but I can unfortunately still get it to crash reliably. Open Blender, switch to Shading tab. Create image texture node and load any image, connect to Metallic input. Create second image texture node and connect to Base Color input. Open file browser from this node and then close it. Open and close it around 3-6 more times. It reliably crashes for me every single time I follow these steps. Blender 2.83 (sub 16), Commit date: 2020-05-13 20:48, Hash 71298a1da971 [blender_2_83_sub_16_2020-05-13_error.log](https://archive.blender.org/developer/F8534452/blender_2_83_sub_16_2020-05-13_error.log) [blender_2_83_sub_16_2020-05-13_blender.crash.txt](https://archive.blender.org/developer/F8534451/blender_2_83_sub_16_2020-05-13_blender.crash.txt) AMD Ryzen 5 2500U / Vega 8 ``` Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD RAVEN (DRM 3.35.0, 5.4.39-1-MANJARO, LLVM 10.0.0) (0x15dd) Version: 20.0.6 ``` ``` I0514 01:37:46.244590 4431 blender_python.cpp:191] Debug flags initialized to: CPU flags: AVX2 : True AVX : True SSE4.1 : True SSE3 : True SSE2 : True BVH layout : BVH8 Split : False CUDA flags: Adaptive Compile : False OptiX flags: CUDA streams : 1 OpenCL flags: Device type : ALL Debug : False Memory limit : 0 Segmentation fault (core dumped) ```

Sergey Sidun commented

2020-05-14 17:39:25 +02:00

Unfortunately still crashes here too, but right now I need to open and close file browser more times to provoke the crash

System Information
Operating system: Linux-5.6.11-arch1-1-x86_64-with-arch 64 Bits
Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.11-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6

Blender Version
Broken: version: 2.90 (sub 1), branch: master, commit date: 2020-05-13 22:51, hash: c8060a78fd

Unfortunately still crashes here too, but right now I need to open and close file browser more times to provoke the crash **System Information** Operating system: Linux-5.6.11-arch1-1-x86_64-with-arch 64 Bits Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.11-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.6 **Blender Version** Broken: version: 2.90 (sub 1), branch: master, commit date: 2020-05-13 22:51, hash: `c8060a78fd`

Clément Foucault commented

2020-05-14 17:51:46 +02:00

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

Clément Foucault reopened this issue

2020-05-14 17:51:46 +02:00

Clément Foucault commented

2020-05-14 17:51:46 +02:00

I cannot reproduce with any of the described procedures. Note that I'm using mesa 20.0.5.

Joshua Anderson commented

2020-05-14 18:02:53 +02:00

I was able to get it to crash by opening usually 4-5 external files. Fonts and images. Much better than it was before, but still a problem

Sergey Sidun commented

2020-05-16 03:44:44 +02:00

I'm very glad to say that after today mesa update problem was solved for me and blender does not crashing anymore. Thank you very much

System Information
Operating system: Linux-5.6.13-arch1-1-x86_64-with-arch 64 Bits
Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.13-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.7

Blender Version
version: 2.90 (sub 2), branch: master, commit date: 2020-05-15 19:12, hash: eaf7d36d66

I just tried old Steam version and it works fine too, so it was probably mesa related problem all that time.

I'm very glad to say that after today mesa update problem was solved for me and blender does not crashing anymore. Thank you very much **System Information** Operating system: Linux-5.6.13-arch1-1-x86_64-with-arch 64 Bits Graphics card: Radeon RX 570 Series (POLARIS10, DRM 3.36.0, 5.6.13-arch1-1, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.7 **Blender Version** version: 2.90 (sub 2), branch: master, commit date: 2020-05-15 19:12, hash: `eaf7d36d66` I just tried old Steam version and it works fine too, so it was probably mesa related problem all that time.

Anton Raves commented

2020-05-17 08:17:56 +02:00

With the overnight update of the Fedora 32 Mesa drivers to version 20.0.7 Blender 50ef801a79b5 no longer crashes and also the current nightly build e5ace51295b9 does not crash upon closing the Preference and File Browser windows! Many thanks Clément (and others!) for your attention, time and patience!

With the overnight update of the Fedora 32 Mesa drivers to version 20.0.7 Blender `50ef801a79b5` no longer crashes and also the current nightly build `e5ace51295b9` does not crash upon closing the Preference and File Browser windows! Many thanks Clément (and others!) for your attention, time and patience!

Ankit Meel commented

2020-05-17 09:27:04 +02:00

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

Ankit Meel closed this issue

2020-05-17 09:27:04 +02:00

Ankit Meel commented

2020-05-17 09:27:04 +02:00

Only @andersmmg , @EricChirnside need to update their status now. Looking at the similarities & their mesa versions, it should be fixed for them too.
So closing.

Only @andersmmg , @EricChirnside need to update their status now. Looking at the similarities & their mesa versions, it should be fixed for them too. So closing.

Joshua Anderson commented

2020-05-18 18:24:14 +02:00

Seems to be working fully for me now, I tried a lot of different image and font files and it never crashed!

Eric commented

2020-05-18 21:49:43 +02:00

@ankitm Though my distro hasn't updated to Mesa 20.0.7 (still on 20.0.6), I haven't been able to reproduce the bug on version: 2.83 (sub 17), branch: master, commit date: 2020-05-18 08:49, hash: 008e964940 so it seems to be fixed. Thanks for everyone's hard work, as always!

LOL, never mind. As I was writing this I had Blender opened in the background and it crashed when I switched back to it. Then I opened it back up and tried my steps as before and it crashed in the same way. I guess I'll wait until Mesa 20.0.7 and try again at that time.

*@ankitm Though my distro hasn't updated to Mesa 20.0.7 (still on 20.0.6), I haven't been able to reproduce the bug on version: 2.83 (sub 17), branch: master, commit date: 2020-05-18 08:49, hash: 008e96494008 so it seems to be fixed. Thanks for everyone's hard work, as always!* LOL, never mind. As I was writing this I had Blender opened in the background and it crashed when I switched back to it. Then I opened it back up and tried my steps as before and it crashed in the same way. I guess I'll wait until Mesa 20.0.7 and try again at that time.

Lucas Newcomb commented

2020-05-19 08:36:07 +02:00

Removed subscriber: @Tony_PJs

Dalai Felinto commented

2021-04-06 15:23:39 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2021-04-06 15:23:39 +02:00

Without this being in the BF Blender project it doesn't show in most of the tags.

@fclem FYI instead of removing 2.93 tag you could have just added "BF Blender" tag that would have automatically removed the 2.93 tag AND kept any BF related tag.

Without this being in the BF Blender project it doesn't show in most of the tags. @fclem FYI instead of removing 2.93 tag you could have just added "BF Blender" tag that would have automatically removed the 2.93 tag AND kept any BF related tag.

Sign in to join this conversation.