void-linux
Blender crashes on startup
Is this a new report?
Yes
System Info
Void 6.6.25_1 x86_64 GenuineIntel notuptodate rrrmFFFFFFFFF
Package(s) Affected
blender-4.0.2_2
Does a report exist for this bug with the project's home (upstream) and/or another distro?
No response
Expected behaviour
Start up... or at least spit out something regarding the GPU not being compatible, because I have no idea if it is (AMD Radeon HD 4650).
But, I also tested it on 2 other PCs, both with older Intel onboard graphics (one has a 2nd gen i3, the other has a G41 GPU, Dual/Quad core era), it just crashes there as well
Actual behaviour
Here is what /tmp/blender.crash.txt holds.
# Blender 4.0.2, Unknown revision
# backtrace
blender(+0xf43dd3) [0x555c3770edd3]
blender(+0x862ea9) [0x555c3702dea9]
/usr/lib/libc.so.6(+0x3f8c0) [0x7fe78a3738c0]
blender(+0xf8a15c) [0x555c3775515c]
blender(+0xf8a1bd) [0x555c377551bd]
blender(+0xf53d04) [0x555c3771ed04]
blender(+0xf6998e) [0x555c3773498e]
blender(+0xf6f124) [0x555c3773a124]
blender(+0x8385e8) [0x555c370035e8]
/usr/lib/libc.so.6(+0x29c4c) [0x7fe78a35dc4c]
/usr/lib/libc.so.6(__libc_start_main+0x85) [0x7fe78a35dd05]
blender(+0x85e8b1) [0x555c370298b1]
# Python backtrace
Steps to reproduce
Try running it on unsupported hardware (in a VM for example, with no GPU passthrough), because I think that is the actual problem, since no one has filed a bug report yet, which means for people with newer hardware and that use it, it works just fine.
Can you share the backtrace with debug symbols? (Add the debug repo and install blender-dbg)
You might need to use gdb, in which case do gdb blender, then do run and when the application crashes, do bt.
@oreo639 OK, here's what it spew.
#0 wm_window_set_drawable (activate=false, win=0x0, wm=0x7fffe4bc6c08) at ../source/blender/windowmanager/intern/wm_window.cc:1235
#1 wm_window_ghostwindow_add (title=0x555558d9b801 "Blender", is_dialog=<optimized out>, win=0x7fffe43acd08, wm=0x7fffe4bc6c08)
at ../source/blender/windowmanager/intern/wm_window.cc:785
#2 wm_window_ghostwindow_ensure (wm=0x7fffe4bc6c08, win=0x7fffe43acd08, is_dialog=<optimized out>)
at ../source/blender/windowmanager/intern/wm_window.cc:817
#3 0x00005555564de1bd in wm_window_ghostwindows_ensure (wm=wm@entry=0x7fffe4bc6c08)
at ../source/blender/windowmanager/intern/wm_window.cc:874
#4 0x00005555564a7d04 in WM_check (C=C@entry=0x7fffe6398b88) at ../source/blender/windowmanager/intern/wm.cc:483
#5 0x00005555564bd98e in wm_homefile_read_ex (C=C@entry=0x7fffe6398b88, params_homefile=params_homefile@entry=0x7fffffffe6b0,
reports=reports@entry=0x0, r_params_file_read_post=r_params_file_read_post@entry=0x7fffffffe6a8)
at ../source/blender/windowmanager/intern/wm_files.cc:1476
#6 0x00005555564c3124 in WM_init (C=C@entry=0x7fffe6398b88, argc=argc@entry=1, argv=argv@entry=0x7fffffffe888)
at ../source/blender/windowmanager/intern/wm_init_exit.cc:302
#7 0x0000555555d8c5e8 in main (argc=1, argv=0x7fffffffe888) at ../source/creator/creator.cc:537
The crash is a nullptr dereference here: https://github.com/blender/blender/blob/v4.0.2/source/blender/windowmanager/intern/wm_window.cc#L1235
What desktop environment are you using? Does this happen with the Blender flatpak?
Yep, it crashes again with the same crash report.
# Blender 4.0.2, Unknown revision
# backtrace
blender(+0xf43dd3) [0x55bff141fdd3]
blender(+0x862ea9) [0x55bff0d3eea9]
/usr/lib/libc.so.6(+0x3f8c0) [0x7f03f56558c0]
blender(+0xf8a15c) [0x55bff146615c]
blender(+0xf8a1bd) [0x55bff14661bd]
blender(+0xf53d04) [0x55bff142fd04]
blender(+0xf6998e) [0x55bff144598e]
blender(+0xf6f124) [0x55bff144b124]
blender(+0x8385e8) [0x55bff0d145e8]
/usr/lib/libc.so.6(+0x29c4c) [0x7f03f563fc4c]
/usr/lib/libc.so.6(__libc_start_main+0x85) [0x7f03f563fd05]
blender(+0x85e8b1) [0x55bff0d3a8b1]
# Python backtrace
@MechDR Try running Blender with different command-line options or environment variables that may help diagnose the issue
blender --debug-all or MESA_DEBUG=1 blender
OK, here is what blender --debug-all says.
Switching to fully guarded memory allocator.
graph_id_tag_update: id=SCScene flags=BASE_FLAGS source=USER_EDIT
DEG_relations_tag_update: Tagging relations for update.
graph_id_tag_update: id=GRScene Collection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRCollection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GROVERRIDE_RESYNC_LEFTOVERS flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRScene Collection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRCollection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GROVERRIDE_RESYNC_LEFTOVERS flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRScene Collection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRCollection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GROVERRIDE_RESYNC_LEFTOVERS flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRScene Collection flags=TRANSFORM, GEOMETRY, COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=TRANSFORM, GEOMETRY, COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=TRANSFORM, GEOMETRY, COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRScene Collection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRCollection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GROVERRIDE_RESYNC_LEFTOVERS flags=COPY_ON_WRITE source=USER_EDIT
DEG_relations_tag_update: Tagging relations for update.
DEG_relations_tag_update: Tagging relations for update.
DEG_relations_tag_update: Tagging relations for update.
graph_id_tag_update: id=GRScene Collection flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=SCScene flags=COPY_ON_WRITE source=USER_EDIT
graph_id_tag_update: id=GRCollection flags=COPY_ON_WRITE source=USER_EDIT
Received X11 Error:
error code: 170
request code: 153
minor code: 0
error text: GLXBadFBConfig
Received X11 Error:
error code: 170
request code: 153
minor code: 0
error text: GLXBadFBConfig
Received X11 Error:
error code: 170
request code: 153
minor code: 0
error text: GLXBadFBConfig
Received X11 Error:
error code: 170
request code: 153
minor code: 0
error text: GLXBadFBConfig
Writing: /tmp/blender.crash.txt
fish: Job 1, 'blender --debug-all' terminated by signal SIGSEGV (Address boundary error)
As for MESA_DEBUG=1 blender, it basically does the same thing as just running blender, crashes and writes to blender.crash.txt.
Writing: /tmp/blender.crash.txt
fish: Job 1, 'MESA_DEBUG=1 blender' terminated by signal SIGSEGV (Address boundary error)
And there is nothing new in blender.crash.txt, it's the same thing as if you just run blender.
# Blender 4.0.2, Unknown revision
# backtrace
blender(+0xf43dd3) [0x5568b1097dd3]
blender(+0x862ea9) [0x5568b09b6ea9]
/usr/lib/libc.so.6(+0x3f8c0) [0x7f90396558c0]
blender(+0xf8a15c) [0x5568b10de15c]
blender(+0xf8a1bd) [0x5568b10de1bd]
blender(+0xf53d04) [0x5568b10a7d04]
blender(+0xf6998e) [0x5568b10bd98e]
blender(+0xf6f124) [0x5568b10c3124]
blender(+0x8385e8) [0x5568b098c5e8]
/usr/lib/libc.so.6(+0x29c4c) [0x7f903963fc4c]
/usr/lib/libc.so.6(__libc_start_main+0x85) [0x7f903963fd05]
blender(+0x85e8b1) [0x5568b09b28b1]
# Python backtrace
I wonder if this problem is caused on Void's side or rather on Blender's side. Any ideas? If it's because Blender is messing something up, I'd go to Blenders GH and create a new issue and link to this one.
I wonder if this problem is caused on Void's side or rather on Blender's side.
I highly doubt it. It is a nullptr dereference in upstream code and was reproduced by OP in the Blender flatpak.
In this case, it calls wm_window_set_drawable(wm, prev_windrawable, false) when wm->windrawable is NULL because GHOST_CreateWindow() fails.
I dug a little and compared Blender 4.0.1 with Blender 3.6.12 (this one and v3.3. work for me) and
GPU_context_active_set(static_cast<GPUContext *>(win->gpuctx));
lead me to
https://github.com/blender/blender/blob/9be62e85b7270d3d2e5bcc846420b91bab3988f9/source/blender/gpu/GPU_context.h#L65
where even the doc string states that it can be NULL (in v4 and v3.6).
This only difference is the STATIC_CASTING in v4.
I will try to see, if
a) removing the 'static_cast' or
b) adding a nullptr-check before casting
will resolve the issue.
win->gpuctx is equivalent to (*win).gpuctx (which dereferences win), in this case win is NULL because GHOST_CreateWindow() failed for whatever reason and wm->windrawable is NULL.
Either way, assuming this can still be reproduced on the latest official release, this should be reported upstream. Personally, I can't reproduce it so there isn't much I can do about it.
I think GHOST_CreateWindow fails in v4, because it uses 'gpuSettings' (https://github.com/blender/blender/blob/9be62e85b7270d3d2e5bcc846420b91bab3988f9/source/blender/windowmanager/intern/wm_window.cc#L734C7-L734C18) for the first time. Before it was 'glSettings' (https://github.com/blender/blender/blob/626a6b1c67997ac2432e91e836db5ed0f2dd8c64/source/blender/windowmanager/intern/wm_window.c#L692). This would be in line with what @MechDR said about PCs without GPU Passthrough. Since I have the same issue as @MechDR I can reproduce it and check, if I can still use 'gSettings', if 'gpuSettings' are not available.
Thanks for your help in locating the bug :D
@MechDR Sorry no, I totally forgot about it, because I had other important stuff to attend to and afterwards I simply forgot about it :/
@MechDR Added my past learnings to that thread. Thanks for creating the ticket, but sadly it got closed immediately, because PCs without dedicated GPU are not supported anymore :/ But I think, we can close this one now, since it's no longer needed (and not caused by void linux)