Blender sometimes crashes when loading a file with unregistered nodes #81419

New Issue

Moritz Brückner · 2020-10-03T18:54:30+02:00

Moritz Brückner commented

2020-10-03 18:54:30 +02:00

System Information
Operating system: Windows 10 64 Bit
Graphics card: Nvidia Geforce GTX 750 Ti

Blender Version
Broken: 2.83.7 release

Short description of error
Sometimes when opening a file with unregistered custom nodes, Blender will crash with an EXCEPTION_ACCESS_VIOLATION error.

Stack trace from Visual Studio:

blender.exe!node_free_node(bNodeTree * ntree, bNode * node) Zeile 2033
	unter C:\blender-git\blender\source\blender\blenkernel\intern\node.c (2033)
blender.exe!ntree_free_data(ID * id) Zeile 227
	unter C:\blender-git\blender\source\blender\blenkernel\intern\node.c (227)
blender.exe!BKE_libblock_free_datablock(ID * id, const int UNUSED_flag) Zeile 136
	unter C:\blender-git\blender\source\blender\blenkernel\intern\lib_id_delete.c (136)
blender.exe!DEG::deg_free_copy_on_write_datablock(ID * id_cow) Zeile 1073
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (1073)
blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Zeile 952
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (952)
blender.exe!DEG::deg_evaluate_copy_on_write(Depsgraph * graph, const DEG::IDNode * id_node) Zeile 1088
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (1088)
blender.exe!std::invoke<void (__cdecl*&)(Depsgraph *,DEG::IDNode const *),Depsgraph *,DEG::IDNode * &>(void(*)(Depsgraph *, const DEG::IDNode *) & _Obj, Depsgraph * && _Arg1, DEG::IDNode * & <_Args2_0>) Zeile 1626
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1626)
blender.exe!std::_Invoker_ret<std::_Unforced,0>::_Call<void (__cdecl*&)(Depsgraph *,DEG::IDNode const *),Depsgraph *,DEG::IDNode * &>(void(*)(Depsgraph *, const DEG::IDNode *) & <_Vals_0>, Depsgraph * && <_Vals_1>, DEG::IDNode * & <_Vals_2>) Zeile 1658
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1658)
blender.exe!std::_Call_binder<std::_Unforced,0,1,void (__cdecl*)(Depsgraph *,DEG::IDNode const *),std::tuple<std::_Ph<1>,DEG::IDNode *>,std::tuple<Depsgraph * &&>>(std::_Invoker_ret<std::_Unforced,0> __formal, std::integer_sequence<unsigned __int64,0,1> __formal, void(*)(Depsgraph *, const DEG::IDNode *) & _Obj, std::tuple<std::_Ph<1>,DEG::IDNode *> & _Tpl, std::tuple<Depsgraph * &&> && _Ut) Zeile 1388
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (1388)
blender.exe!std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &>::operator()<Depsgraph *>(Depsgraph * && <_Unbargs_0>) Zeile 1427
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (1427)
blender.exe!std::invoke<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> &,Depsgraph *>(std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> & _Obj, Depsgraph * && _Arg1) Zeile 1626
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1626)
blender.exe!std::_Invoker_ret<void,1>::_Call<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> &,Depsgraph *>(std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> & <_Vals_0>, Depsgraph * && <_Vals_1>) Zeile 1641
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1641)
blender.exe!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &>,void,Depsgraph *>::_Do_call(Depsgraph * && <_Args_0>) Zeile 904
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (904)
blender.exe!std::_Func_class<void,Depsgraph *>::operator()(Depsgraph * <_Args_0>) Zeile 952
	unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (952)
blender.exe!DEG::`anonymous namespace'::evaluate_node(const DEG::`anonymous-namespace'::DepsgraphEvalState * state, DEG::OperationNode * operation_node) Zeile 117
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (117)
blender.exe!DEG::`anonymous namespace'::deg_task_run_func(TaskPool * pool, void * taskdata, int thread_id) Zeile 129
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (129)
blender.exe!BLI_task_pool_work_and_wait(TaskPool * pool) Zeile 939
	unter C:\blender-git\blender\source\blender\blenlib\intern\task_pool.cc (939)
blender.exe!BLI_task_pool_work_wait_and_reset(TaskPool * pool) Zeile 970
	unter C:\blender-git\blender\source\blender\blenlib\intern\task_pool.cc (970)
blender.exe!DEG::deg_evaluate_on_refresh(DEG::Depsgraph * graph) Zeile 403
	unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (403)
blender.exe!DEG_evaluate_on_refresh(Main * bmain, Depsgraph * graph) Zeile 65
	unter C:\blender-git\blender\source\blender\depsgraph\intern\depsgraph_eval.cc (65)
blender.exe!scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Zeile 1329
	unter C:\blender-git\blender\source\blender\blenkernel\intern\scene.c (1329)
blender.exe!BKE_scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain) Zeile 1367
	unter C:\blender-git\blender\source\blender\blenkernel\intern\scene.c (1367)
blender.exe!wm_event_do_depsgraph(bContext * C, bool is_after_open_file) Zeile 360
	unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (360)
blender.exe!wm_event_do_refresh_wm_and_depsgraph(bContext * C) Zeile 387
	unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (387)
blender.exe!wm_event_do_notifiers(bContext * C) Zeile 552
	unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (552)
blender.exe!WM_main(bContext * C) Zeile 456
	unter C:\blender-git\blender\source\blender\windowmanager\intern\wm.c (456)
blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Zeile 530
	unter C:\blender-git\blender\source\creator\creator.c (530)
blender.exe!invoke_main() Zeile 79
	unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (79)
blender.exe!__scrt_common_main_seh() Zeile 288
	unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288)
blender.exe!__scrt_common_main() Zeile 331
	unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (331)
blender.exe!mainCRTStartup() Zeile 17
	unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp (17)
kernel32.dll!00007ffca1667bd4()
ntdll.dll!00007ffca1e0ce51()

The exception in line 2033 of node.c says that there is an access violation when reading at position 0xFFFFFFFFFFFFFFFF. node->typeinfo does exist (is not null), but freefunc (and actually most of the other attributes) point to 0xdddd.... Because of that, I think that this bug might be caused by a similar issue as described in #72833.

I'm not sure if a core dump helps you, it's quite large (1GB + another GB for the .pdb file) so if you need it I can look for a way to make it available to you. I'm not a C or C++ dev so I don't know what is helpful.

EDIT: I think this crash is caused by opening files files with nodes that were registered while the file was originaly saved but not anymore.

Exact steps for others to reproduce the error
It's a bit complicated because it doesn't happen all the time. The particular file(s) where I observed this issue use nodes from an addon (Armory3D) which supports per-project custom nodes which get registered via a on_load_post() handler (so there is a delay between opening the file and registering the nodes). I'm not entirely sure, but it seems like the crash occurs when the nodes are registered again. The crash even occurs when unregistering the nodes before saving the file.

Because of that complicated setup (addon required + project setup + custom node package) I will go without an example file. If you aren't able to find the cause without one, please tell me so that I can prepare a minimal project setup for you.

Thank you very much!

Original issue: https://github.com/armory3d/armory/issues/1890

**System Information** Operating system: Windows 10 64 Bit Graphics card: Nvidia Geforce GTX 750 Ti **Blender Version** Broken: 2.83.7 release **Short description of error** Sometimes when opening a file with unregistered custom nodes, Blender will crash with an `EXCEPTION_ACCESS_VIOLATION` error. **Stack trace from Visual Studio:** ``` blender.exe!node_free_node(bNodeTree * ntree, bNode * node) Zeile 2033 unter C:\blender-git\blender\source\blender\blenkernel\intern\node.c (2033) blender.exe!ntree_free_data(ID * id) Zeile 227 unter C:\blender-git\blender\source\blender\blenkernel\intern\node.c (227) blender.exe!BKE_libblock_free_datablock(ID * id, const int UNUSED_flag) Zeile 136 unter C:\blender-git\blender\source\blender\blenkernel\intern\lib_id_delete.c (136) blender.exe!DEG::deg_free_copy_on_write_datablock(ID * id_cow) Zeile 1073 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (1073) blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Zeile 952 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (952) blender.exe!DEG::deg_evaluate_copy_on_write(Depsgraph * graph, const DEG::IDNode * id_node) Zeile 1088 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc (1088) blender.exe!std::invoke<void (__cdecl*&)(Depsgraph *,DEG::IDNode const *),Depsgraph *,DEG::IDNode * &>(void(*)(Depsgraph *, const DEG::IDNode *) & _Obj, Depsgraph * && _Arg1, DEG::IDNode * & <_Args2_0>) Zeile 1626 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1626) blender.exe!std::_Invoker_ret<std::_Unforced,0>::_Call<void (__cdecl*&)(Depsgraph *,DEG::IDNode const *),Depsgraph *,DEG::IDNode * &>(void(*)(Depsgraph *, const DEG::IDNode *) & <_Vals_0>, Depsgraph * && <_Vals_1>, DEG::IDNode * & <_Vals_2>) Zeile 1658 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1658) blender.exe!std::_Call_binder<std::_Unforced,0,1,void (__cdecl*)(Depsgraph *,DEG::IDNode const *),std::tuple<std::_Ph<1>,DEG::IDNode *>,std::tuple<Depsgraph * &&>>(std::_Invoker_ret<std::_Unforced,0> __formal, std::integer_sequence<unsigned __int64,0,1> __formal, void(*)(Depsgraph *, const DEG::IDNode *) & _Obj, std::tuple<std::_Ph<1>,DEG::IDNode *> & _Tpl, std::tuple<Depsgraph * &&> && _Ut) Zeile 1388 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (1388) blender.exe!std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &>::operator()<Depsgraph *>(Depsgraph * && <_Unbargs_0>) Zeile 1427 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (1427) blender.exe!std::invoke<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> &,Depsgraph *>(std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> & _Obj, Depsgraph * && _Arg1) Zeile 1626 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1626) blender.exe!std::_Invoker_ret<void,1>::_Call<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> &,Depsgraph *>(std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &> & <_Vals_0>, Depsgraph * && <_Vals_1>) Zeile 1641 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits (1641) blender.exe!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl&)(Depsgraph *,DEG::IDNode const *),std::_Ph<1> const &,DEG::IDNode * &>,void,Depsgraph *>::_Do_call(Depsgraph * && <_Args_0>) Zeile 904 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (904) blender.exe!std::_Func_class<void,Depsgraph *>::operator()(Depsgraph * <_Args_0>) Zeile 952 unter A:\Programs\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional (952) blender.exe!DEG::`anonymous namespace'::evaluate_node(const DEG::`anonymous-namespace'::DepsgraphEvalState * state, DEG::OperationNode * operation_node) Zeile 117 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (117) blender.exe!DEG::`anonymous namespace'::deg_task_run_func(TaskPool * pool, void * taskdata, int thread_id) Zeile 129 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (129) blender.exe!BLI_task_pool_work_and_wait(TaskPool * pool) Zeile 939 unter C:\blender-git\blender\source\blender\blenlib\intern\task_pool.cc (939) blender.exe!BLI_task_pool_work_wait_and_reset(TaskPool * pool) Zeile 970 unter C:\blender-git\blender\source\blender\blenlib\intern\task_pool.cc (970) blender.exe!DEG::deg_evaluate_on_refresh(DEG::Depsgraph * graph) Zeile 403 unter C:\blender-git\blender\source\blender\depsgraph\intern\eval\deg_eval.cc (403) blender.exe!DEG_evaluate_on_refresh(Main * bmain, Depsgraph * graph) Zeile 65 unter C:\blender-git\blender\source\blender\depsgraph\intern\depsgraph_eval.cc (65) blender.exe!scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Zeile 1329 unter C:\blender-git\blender\source\blender\blenkernel\intern\scene.c (1329) blender.exe!BKE_scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain) Zeile 1367 unter C:\blender-git\blender\source\blender\blenkernel\intern\scene.c (1367) blender.exe!wm_event_do_depsgraph(bContext * C, bool is_after_open_file) Zeile 360 unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (360) blender.exe!wm_event_do_refresh_wm_and_depsgraph(bContext * C) Zeile 387 unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (387) blender.exe!wm_event_do_notifiers(bContext * C) Zeile 552 unter C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c (552) blender.exe!WM_main(bContext * C) Zeile 456 unter C:\blender-git\blender\source\blender\windowmanager\intern\wm.c (456) blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Zeile 530 unter C:\blender-git\blender\source\creator\creator.c (530) blender.exe!invoke_main() Zeile 79 unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (79) blender.exe!__scrt_common_main_seh() Zeile 288 unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288) blender.exe!__scrt_common_main() Zeile 331 unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (331) blender.exe!mainCRTStartup() Zeile 17 unter D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp (17) kernel32.dll!00007ffca1667bd4() ntdll.dll!00007ffca1e0ce51() ``` The exception in line 2033 of node.c says that there is an access violation when reading at position `0xFFFFFFFFFFFFFFFF`. `node->typeinfo` does exist (is not null), but `freefunc` (and actually most of the other attributes) point to `0xdddd...`. Because of that, I think that this bug might be caused by a similar issue as described in #72833. I'm not sure if a core dump helps you, it's quite large (1GB + another GB for the .pdb file) so if you need it I can look for a way to make it available to you. I'm not a C or C++ dev so I don't know what is helpful. **EDIT**: I think this crash is caused by opening files files with nodes that were registered while the file was originaly saved but not anymore. **Exact steps for others to reproduce the error** It's a bit complicated because it doesn't happen all the time. The particular file(s) where I observed this issue use nodes from an addon (Armory3D) which supports per-project custom nodes which get registered via a `on_load_post()` handler (so there is a delay between opening the file and registering the nodes). I'm not entirely sure, but it seems like the crash occurs when the nodes are registered again. The crash even occurs when unregistering the nodes before saving the file. Because of that complicated setup (addon required + project setup + custom node package) I will go without an example file. If you aren't able to find the cause without one, please tell me so that I can prepare a minimal project setup for you. Thank you very much! *Original issue*: https://github.com/armory3d/armory/issues/1890

Moritz Brückner commented

2020-10-03 18:54:30 +02:00

Added subscriber: @timodriaan

Omar Emara commented

2022-03-10 14:18:25 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-03-10 14:18:25 +01:00

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

Omar Emara commented

2022-03-10 14:18:25 +01:00

We require simple instructions to investigate such issue, debugging a large add-on like this is too time consuming. I see you managed to to narrow the issue down in your upstream report. Can you create a minimal script and a blend file that reproduces this issue?

Moritz Brückner commented

2022-03-11 00:04:11 +01:00

Yes, I'm on it, but I'm not sure if it will be successful since there is a lot going on in the addon code that might interfere. It's still a bit uncertain where exactly the issue is caused, but I will try my best and will write again soon once I know more. I still suspect that the issue is similar to https://developer.blender.org/T72833, so it might make sense to investigate that for the time being.

Please let me know if the core dump mentioned in my original post is of any interest. Please also let me know if it isn't, so that I can finally delete it :) However I don't think I have the .pdb anymore. I also have a few screenshots of the VS debugging session at that time that I can share with you (including stack traces and some variable values at the time of encountering the exception breakpoint), however they lack a bit of context and were mostly meant for me to rember stuff I wanted to include in this report.

Yes, I'm on it, but I'm not sure if it will be successful since there is a lot going on in the addon code that might interfere. It's still a bit uncertain where exactly the issue is caused, but I will try my best and will write again soon once I know more. I still suspect that the issue is similar to https://developer.blender.org/T72833, so it might make sense to investigate that for the time being. Please let me know if the core dump mentioned in my original post is of any interest. Please also let me know if it isn't, so that I can finally delete it :) However I don't think I have the .pdb anymore. I also have a few screenshots of the VS debugging session at that time that I can share with you (including stack traces and some variable values at the time of encountering the exception breakpoint), however they lack a bit of context and were mostly meant for me to rember stuff I wanted to include in this report.

Omar Emara commented

2022-03-11 08:09:11 +01:00

I doubt a core dump will be useful, so feel free to delete it. I can't replicate #72833 myself now and it is already confirmed for two years with no solution, so it would be better if we can reproduce it independently.

Moritz Brückner commented

2022-03-13 23:12:01 +01:00

I tried it again and can't seem to reproduce the crash anymore, even though it's difficult to tell with certainty due to the random nature of the crashes. I also spent a few hours on creating a minimal example script, without success.

So we can probably consider this fixed. I asked in the original issue if someone else is still able to reproduce it, but if not or if there is no answer in the next few days I would say this bug report can be closed.

Thanks for your patience :)

I tried it again and can't seem to reproduce the crash anymore, even though it's difficult to tell with certainty due to the random nature of the crashes. I also spent a few hours on creating a minimal example script, without success. So we can probably consider this fixed. I asked in the [original issue](https://github.com/armory3d/armory/issues/1890) if someone else is still able to reproduce it, but if not or if there is no answer in the next few days I would say this bug report can be closed. Thanks for your patience :)

Moritz Brückner commented

2022-03-16 20:44:46 +01:00

I asked in the original issue if someone else is still able to reproduce it, but if not or if there is no answer in the next few days I would say this bug report can be closed.

No new answers in the linked original issue and I still can't reproduce anymore, so I think this bug report can be closed now :) Thanks again!

> I asked in the original issue if someone else is still able to reproduce it, but if not or if there is no answer in the next few days I would say this bug report can be closed. No new answers in the linked original issue and I still can't reproduce anymore, so I think this bug report can be closed now :) Thanks again!

Omar Emara commented

2022-03-16 21:03:20 +01:00

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

Omar Emara closed this issue

2022-03-16 21:03:20 +01:00

Moritz Brückner commented

2022-03-21 17:50:28 +01:00

Unfortunately I found an old file where I can still reproduce the crashes, so there still seems to be a problem when loading files with custom nodes.

Because I'm still not able to provide a small example addon where the crashes are reproducable, the best I can do is to provide you with the project files that lead to the crash if you install the original addon. It hopefully doesn't take more than five or ten minutes to set everything up:

Download ArmorySDK-2022-3.zip from https:*armory.itch.io/armory3d and unzip it (or do a recursive clone of https:*github.com/armory3d/armsdk/tree/22.03, but it's slower)
In Blender 2.93 LTS, install the armory.py file from the extracted folder as an add-on. As long as you work with the addon, keep the extracted folder at the same location.
Open the CustomNodesCrash.blend from the following project (extract and leave the folder structure intact):

{F12938616}

Blender will crash in 9 of 10 cases.

Unfortunately I found an old file where I can still reproduce the crashes, so there still seems to be a problem when loading files with custom nodes. Because I'm still not able to provide a small example addon where the crashes are reproducable, the best I can do is to provide you with the project files that lead to the crash if you install the original addon. It hopefully doesn't take more than five or ten minutes to set everything up: 1. Download `ArmorySDK-2022-3.zip` from https:*armory.itch.io/armory3d and **unzip it** (or do a recursive clone of https:*github.com/armory3d/armsdk/tree/22.03, but it's slower) 2. In Blender 2.93 LTS, install the `armory.py` file from the extracted folder as an add-on. As long as you work with the addon, keep the extracted folder at the same location. 3. Open the `CustomNodesCrash.blend` from the following project (extract and leave the folder structure intact): ``` {F12938616} ``` 4. Blender will crash in 9 of 10 cases.

Omar Emara commented

2022-03-21 19:01:11 +01:00

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

Omar Emara reopened this issue

2022-03-21 19:01:11 +01:00

Omar Emara commented

2022-03-24 12:23:36 +01:00

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

Omar Emara commented

2022-03-24 12:23:36 +01:00

I can replicate the crash as described, but I feel like this might be due to a corrupt file which was saved when there was a bug at some point.
The question is, can we create a file from scratch that reproduces this issue?

I can replicate the crash as described, but I feel like this might be due to a corrupt file which was saved when there was a bug at some point. The question is, can we create a file from scratch that reproduces this issue?

Moritz Brückner commented

2022-03-25 18:38:06 +01:00

I'm not able to reproduce it otherwise, unfortunately. So maybe it's only the file, yes.

However other users of the addon are still reporting that using nodes that are loaded and registered after a file was opened still lead to random crashes in 2.93.8, but not necessarily directly after loading the file but rather when interacting with the node tree (in various ways). Here's a crash log from a user, maybe this can help?

Perfect_Stealth.crash.txt

There are some Python exceptions at the top that I will try to fix, but I think they are rather unrelated to the crash. The actual python backtrace at the very bottom of the crash report comes from this line: 41f0ee249f/blender/arm/logicnode/arm_nodes.py (L690). It is executed when the user adds a node to the tree. Interestingly the C/C++ stack trace looks very similar to the one at the very top of this bug report, so it might be the same issue after all.

The file that was causing the above crash was created in the last month, so it shouldn't be an incompatibility in this case.

Thanks again for your patience, I'm sorry that I can't provide you with better information.

I'm not able to reproduce it otherwise, unfortunately. So maybe it's only the file, yes. However other users of the addon are still reporting that using nodes that are loaded and registered after a file was opened still lead to random crashes in 2.93.8, but not necessarily directly after loading the file but rather when interacting with the node tree (in various ways). Here's a crash log from a user, maybe this can help? [Perfect_Stealth.crash.txt](https://archive.blender.org/developer/F12945886/Perfect_Stealth.crash.txt) There are some Python exceptions at the top that I will try to fix, but I think they are rather unrelated to the crash. The actual python backtrace at the very bottom of the crash report comes from this line: https://github.com/armory3d/armory/blob/41f0ee249f85de48422d9c37dd5e574fab87a2ee/blender/arm/logicnode/arm_nodes.py#L690. It is executed when the user adds a node to the tree. Interestingly the C/C++ stack trace looks very similar to the one at the very top of this bug report, so it might be the same issue after all. The file that was causing the above crash was created in the last month, so it shouldn't be an incompatibility in this case. Thanks again for your patience, I'm sorry that I can't provide you with better information.

Omar Emara commented

2022-03-25 18:39:52 +01:00

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

Philipp Oeser commented

2022-03-29 15:04:34 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-03-29 15:04:34 +02:00

In #81419#1327045, @timodriaan wrote:
Unfortunately I found an old file where I can still reproduce the crashes, so there still seems to be a problem when loading files with custom nodes.

Because I'm still not able to provide a small example addon where the crashes are reproducable, the best I can do is to provide you with the project files that lead to the crash if you install the original addon. It hopefully doesn't take more than five or ten minutes to set everything up:

Download ArmorySDK-2022-3.zip from https:*armory.itch.io/armory3d and unzip it (or do a recursive clone of https:*github.com/armory3d/armsdk/tree/22.03, but it's slower)

In Blender 2.93 LTS, install the armory.py file from the extracted folder as an add-on. As long as you work with the addon, keep the extracted folder at the same location.

Open the CustomNodesCrash.blend from the following project (extract and leave the folder structure intact):

CustomNodesCrash.zip
4. Blender will crash in 9 of 10 cases.

Cannot reproduce here

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44
version: 2.93.8, branch: master, commit date: 2022-02-01 21:14, hash: `rB09da7f489ad9`

> In #81419#1327045, @timodriaan wrote: > Unfortunately I found an old file where I can still reproduce the crashes, so there still seems to be a problem when loading files with custom nodes. > > Because I'm still not able to provide a small example addon where the crashes are reproducable, the best I can do is to provide you with the project files that lead to the crash if you install the original addon. It hopefully doesn't take more than five or ten minutes to set everything up: > > 1. Download `ArmorySDK-2022-3.zip` from https:*armory.itch.io/armory3d and **unzip it** (or do a recursive clone of https:*github.com/armory3d/armsdk/tree/22.03, but it's slower) > 2. In Blender 2.93 LTS, install the `armory.py` file from the extracted folder as an add-on. As long as you work with the addon, keep the extracted folder at the same location. > 3. Open the `CustomNodesCrash.blend` from the following project (extract and leave the folder structure intact): > > [CustomNodesCrash.zip](https://archive.blender.org/developer/F12938616/CustomNodesCrash.zip) > 4. Blender will crash in 9 of 10 cases. Cannot reproduce here ``` **System Information** Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44 version: 2.93.8, branch: master, commit date: 2022-02-01 21:14, hash: `rB09da7f489ad9` ```

Omar Emara commented

2022-04-05 15:20:17 +02:00

Added subscribers: @JacquesLucke, @mont29

Omar Emara commented

2022-04-05 15:20:17 +02:00

@JacquesLucke @mont29 While we can replicate this, we still haven't been able to create simplified reproduction steps yet, but could you take a quick look at the stack trace and see if anything immediately comes to mind?

Jacques Lucke commented

2022-04-07 15:44:31 +02:00

ASAN report: P2888

Based on a first look at the problem, the root issue seems to be that node_free_type current cannot update all nodes that have a pointer to the node type. This is also mentioned in a comment. It does not update nodes in cow copies in the depsgraph currently.
This has to be redesigned a bit, but I'm not 100% sure how yet. Maybe we could just tag unregistered node types instead of actually freeing them.

The problem is probably not that there are unregistered nodes, but that you unregister nodes that are still used. Based on a quick look at the addon, it seems like you reregister some/all nodes when loading a file, is that correct? Why?

ASAN report: [P2888](https://archive.blender.org/developer/P2888.txt) Based on a first look at the problem, the root issue seems to be that `node_free_type` current cannot update all nodes that have a pointer to the node type. This is also mentioned in a comment. It does not update nodes in cow copies in the depsgraph currently. This has to be redesigned a bit, but I'm not 100% sure how yet. Maybe we could just tag unregistered node types instead of actually freeing them. The problem is probably not that there are unregistered nodes, but that you unregister nodes that are still used. Based on a quick look at the addon, it seems like you reregister some/all nodes when loading a file, is that correct? Why?

Hans Goudey commented

2022-04-07 15:59:55 +02:00

Added subscriber: @HooglyBoogly

Moritz Brückner commented

2022-04-08 21:05:03 +02:00

Great that you were able to pinpoint it!

Based on a quick look at the addon, it seems like you reregister some/all nodes when loading a file, is that correct? Why?

Yes, that's correct. Because Blender only allows to install addons as single .py files or from a .zip file, the addon is split into a "core" script and the SDK with the actual addon code which is loaded by the core script. We allow users to use per-project SDKs to keep the used dependecies fixed for a given project and allow them to modify it to their needs, so the nodes potentially need to be re-registered when opening files because the file might use a different SDK with a different version of the registered nodes. However I'm not the original author of that code, so I can't tell you with complete certainty, maybe there are more reasons for it. The whole thing can probably be optimized because there currently are no checks whatsoever whether this is actually required, but we probably can't get rid of it completely.

Great that you were able to pinpoint it! > Based on a quick look at the addon, it seems like you reregister some/all nodes when loading a file, is that correct? Why? Yes, that's correct. Because Blender only allows to install addons as single .py files or from a .zip file, the addon is split into a "core" script and the SDK with the actual addon code which is loaded by the core script. We allow users to use per-project SDKs to keep the used dependecies fixed for a given project and allow them to modify it to their needs, so the nodes potentially need to be re-registered when opening files because the file might use a different SDK with a different version of the registered nodes. However I'm not the original author of that code, so I can't tell you with complete certainty, maybe there are more reasons for it. The whole thing can probably be optimized because there currently are no checks whatsoever whether this is actually required, but we probably can't get rid of it completely.

Philipp Oeser commented

2022-09-01 13:06:41 +02:00

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

Philipp Oeser commented

2022-09-01 13:06:41 +02:00

@JacquesLucke : do you consider this confirmed?

Jacques Lucke commented

2022-09-01 13:12:19 +02:00

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

Jacques Lucke commented

2022-09-01 13:12:19 +02:00

Yeah, it's a bug. The problem is described in #81419#1337435. Would still be nice to get a simplified file to reproduce this though.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender sometimes crashes when loading a file with unregistered nodes #81419