Duplicate Object, then Linked Duplicate Object, then Repeat Last Tool causes crash #77867

Closed
opened 3 years ago by heavypoly · 32 comments

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 441.20

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-12 17:01, hash: fd8d245e6a
Worked: 2.83.0

Short description of error
Crash when redoing Duplicate Linked several times in a row
ShiftD AltD Crash.mkv

Exact steps for others to reproduce the error

  • On a new scene, with default cube, Shift D (move and confirm),
  • then Alt D (move and confirm)
  • then Shift R R R R ... repeatedly until it crashes
**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 441.20 **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-12 17:01, hash: `fd8d245e6a` Worked: 2.83.0 **Short description of error** Crash when redoing Duplicate Linked several times in a row [ShiftD AltD Crash.mkv](https://archive.blender.org/developer/F8626619/ShiftD_AltD_Crash.mkv) **Exact steps for others to reproduce the error** - On a new scene, with default cube, Shift D (move and confirm), - then Alt D (move and confirm) - then Shift R R R R ... repeatedly until it crashes
Poster

Added subscriber: @heavypoly

Added subscriber: @heavypoly
Owner

#78098 was marked as duplicate of this issue

#78098 was marked as duplicate of this issue
Owner

#78448 was marked as duplicate of this issue

#78448 was marked as duplicate of this issue
Owner

#77547 was marked as duplicate of this issue

#77547 was marked as duplicate of this issue
Collaborator

Added subscriber: @deadpin

Added subscriber: @deadpin
Collaborator

I can confirm this crash here as well using a slightly newer build even. However, it sometimes doesn't happen during the first shift-d, alt-d, repeat cycle. It usually happens on the second attempt for me.

Also, I cannot get a good stack trace for the issue. Of the 3 times I attempted it, I'm getting crashes in 3 different areas... 2 of those have BLI_task_* functions in the stack somewhere so there's a good chance this is threading related :-/

[EDIT] Actually, my 3 crashes happen when undo'ing and not strictly with repeating last.

I can confirm this crash here as well using a slightly newer build even. However, it sometimes doesn't happen during the first shift-d, alt-d, repeat cycle. It usually happens on the second attempt for me. Also, I cannot get a good stack trace for the issue. Of the 3 times I attempted it, I'm getting crashes in 3 different areas... 2 of those have BLI_task_* functions in the stack somewhere so there's a good chance this is threading related :-/ [EDIT] Actually, my 3 crashes happen when undo'ing and not strictly with repeating last.
Collaborator

Added subscriber: @mano-wii

Added subscriber: @mano-wii
Collaborator

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

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

I cannot reproduce this with the current development versions of Blender:

Go to File → Defaults → Load Factory Settings and then load your file to see if you still can reproduce this issue.

If the problem persists, please give us more clear instructions on how to reproduce it from scratch.

I cannot reproduce this with the current development versions of Blender: - Please try the latest daily build: https://builder.blender.org/download/ Go to File → Defaults → Load Factory Settings and then load your file to see if you still can reproduce this issue. If the problem persists, please give us more clear instructions on how to reproduce it from scratch.
Poster

ShiftD AltD Crash.mkv

Here's a video showing the exact steps.
Using today's daily build from builder.blender.org and load factory settings.

[ShiftD AltD Crash.mkv](https://archive.blender.org/developer/F8626619/ShiftD_AltD_Crash.mkv) Here's a video showing the exact steps. Using today's daily build from builder.blender.org and load factory settings.
Collaborator

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

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

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

Changed status from 'Needs Triage' to: 'Confirmed'
Collaborator

I can confirm in Release build only.
But I'm still not sure what causes the crash.
For the traceback it seems to be on Depsgraph.

>	blender.exe!MEM_lockfree_mallocN(unsigned __int64 len, const unsigned char * str) Line 273	C

 	blender.exe!DEG::DepsNodeFactoryImpl<DEG::OperationNode>::create_node(const ID * id, const char * subdata, const char * name) Line 52	C++
 	blender.exe!DEG::ComponentNode::add_operation(const std::function<void __cdecl(Depsgraph *)> & op, DEG::OperationCode opcode, const char * name, int name_tag) Line 180	C++
 	blender.exe!DEG::DepsgraphNodeBuilder::add_operation_node(DEG::ComponentNode * comp_node, DEG::OperationCode opcode, const std::function<void __cdecl(Depsgraph *)> & op, const char * name, int name_tag) Line 215	C++
 	blender.exe!DEG::DepsgraphNodeBuilder::add_operation_node(ID * id, DEG::NodeType comp_type, DEG::OperationCode opcode, const std::function<void __cdecl(Depsgraph *)> & op, const char * name, int name_tag) Line 249	C++
 	blender.exe!DEG::DepsgraphNodeBuilder::build_object_transform(Object * object) Line 828	C++
 	blender.exe!DEG::DepsgraphNodeBuilder::build_object(int base_index, Object * object, DEG::eDepsNode_LinkedState_Type linked_state, bool is_visible) Line 601	C++
 	blender.exe!DEG::DepsgraphNodeBuilder::build_view_layer(Scene * scene, ViewLayer * view_layer, DEG::eDepsNode_LinkedState_Type linked_state) Line 117	C++
 	blender.exe!DEG_graph_build_from_view_layer(Depsgraph * graph, Main * bmain, Scene * scene, ViewLayer * view_layer) Line 256	C++
 	blender.exe!scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Line 1477	C
 	blender.exe!createTransData(bContext * C, TransInfo * t) Line 1143	C
 	blender.exe!initTransform(bContext * C, TransInfo * t, wmOperator * op, const wmEvent * event, int mode) Line 1915	C
 	blender.exe!transformops_data(bContext * C, wmOperator * op, const wmEvent * event) Line 394	C
 	blender.exe!transform_exec(bContext * C, wmOperator * op) Line 488	C
 	blender.exe!wm_macro_exec(bContext * C, wmOperator * op) Line 335	C
 	blender.exe!wm_operator_exec(bContext * C, wmOperator * op, const bool repeat, const bool store) Line 1002	C
 	blender.exe!WM_operator_repeat_last(bContext * C, wmOperator * op) Line 1084	C
 	blender.exe!repeat_last_exec(bContext * C, wmOperator * UNUSED_op) Line 3690	C
 	blender.exe!wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Line 1296	C
 	blender.exe!wm_handler_operator_call(bContext * C, ListBase * handlers, wmEventHandler * handler_base, wmEvent * event, PointerRNA * properties, const unsigned char * kmi_idname) Line 2116	C
 	blender.exe!wm_handlers_do_keymap_with_keymap_handler(bContext * C, wmEvent * event, ListBase * handlers, wmEventHandler_Keymap * handler, wmKeyMap * keymap, const bool do_debug_handler) Line 2426	C
 	blender.exe!wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Line 2727	C
 	blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 2949	C
 	blender.exe!wm_event_do_handlers(bContext * C) Line 3395	C
 	blender.exe!WM_main(bContext * C) Line 478	C
 	blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 534	C
 	[External Code]	

I can confirm in Release build only. But I'm still not sure what causes the crash. For the traceback it seems to be on Depsgraph. ``` > blender.exe!MEM_lockfree_mallocN(unsigned __int64 len, const unsigned char * str) Line 273 C blender.exe!DEG::DepsNodeFactoryImpl<DEG::OperationNode>::create_node(const ID * id, const char * subdata, const char * name) Line 52 C++ blender.exe!DEG::ComponentNode::add_operation(const std::function<void __cdecl(Depsgraph *)> & op, DEG::OperationCode opcode, const char * name, int name_tag) Line 180 C++ blender.exe!DEG::DepsgraphNodeBuilder::add_operation_node(DEG::ComponentNode * comp_node, DEG::OperationCode opcode, const std::function<void __cdecl(Depsgraph *)> & op, const char * name, int name_tag) Line 215 C++ blender.exe!DEG::DepsgraphNodeBuilder::add_operation_node(ID * id, DEG::NodeType comp_type, DEG::OperationCode opcode, const std::function<void __cdecl(Depsgraph *)> & op, const char * name, int name_tag) Line 249 C++ blender.exe!DEG::DepsgraphNodeBuilder::build_object_transform(Object * object) Line 828 C++ blender.exe!DEG::DepsgraphNodeBuilder::build_object(int base_index, Object * object, DEG::eDepsNode_LinkedState_Type linked_state, bool is_visible) Line 601 C++ blender.exe!DEG::DepsgraphNodeBuilder::build_view_layer(Scene * scene, ViewLayer * view_layer, DEG::eDepsNode_LinkedState_Type linked_state) Line 117 C++ blender.exe!DEG_graph_build_from_view_layer(Depsgraph * graph, Main * bmain, Scene * scene, ViewLayer * view_layer) Line 256 C++ blender.exe!scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Line 1477 C blender.exe!createTransData(bContext * C, TransInfo * t) Line 1143 C blender.exe!initTransform(bContext * C, TransInfo * t, wmOperator * op, const wmEvent * event, int mode) Line 1915 C blender.exe!transformops_data(bContext * C, wmOperator * op, const wmEvent * event) Line 394 C blender.exe!transform_exec(bContext * C, wmOperator * op) Line 488 C blender.exe!wm_macro_exec(bContext * C, wmOperator * op) Line 335 C blender.exe!wm_operator_exec(bContext * C, wmOperator * op, const bool repeat, const bool store) Line 1002 C blender.exe!WM_operator_repeat_last(bContext * C, wmOperator * op) Line 1084 C blender.exe!repeat_last_exec(bContext * C, wmOperator * UNUSED_op) Line 3690 C blender.exe!wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Line 1296 C blender.exe!wm_handler_operator_call(bContext * C, ListBase * handlers, wmEventHandler * handler_base, wmEvent * event, PointerRNA * properties, const unsigned char * kmi_idname) Line 2116 C blender.exe!wm_handlers_do_keymap_with_keymap_handler(bContext * C, wmEvent * event, ListBase * handlers, wmEventHandler_Keymap * handler, wmKeyMap * keymap, const bool do_debug_handler) Line 2426 C blender.exe!wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Line 2727 C blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 2949 C blender.exe!wm_event_do_handlers(bContext * C) Line 3395 C blender.exe!WM_main(bContext * C) Line 478 C blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 534 C [External Code] ```
Collaborator

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker
Collaborator

After further testing, it seems that the source of the problem is in draw_manager.
Commenting on that line seems to have resolved so far:

diff --git a/source/blender/draw/intern/draw_cache_extract_mesh.c b/source/blender/draw/intern/draw_cache_extract_mesh.c
index f3dc8f0fd2a..37bedd811d3 100644
--- a/source/blender/draw/intern/draw_cache_extract_mesh.c
+++ b/source/blender/draw/intern/draw_cache_extract_mesh.c
@@ -440,7 +440,7 @@ static void mesh_render_data_free(MeshRenderData *mr)
   MEM_SAFE_FREE(mr->loop_normals);
 
   MEM_SAFE_FREE(mr->lverts);
-  MEM_SAFE_FREE(mr->ledges);
+  //MEM_SAFE_FREE(mr->ledges);
 
   MEM_freeN(mr);
 }

@Jeroen-Bakker, does this have anything to do with recent changes to fix the wires drawing problem?

After further testing, it seems that the source of the problem is in draw_manager. Commenting on that line seems to have resolved so far: ``` diff --git a/source/blender/draw/intern/draw_cache_extract_mesh.c b/source/blender/draw/intern/draw_cache_extract_mesh.c index f3dc8f0fd2a..37bedd811d3 100644 --- a/source/blender/draw/intern/draw_cache_extract_mesh.c +++ b/source/blender/draw/intern/draw_cache_extract_mesh.c @@ -440,7 +440,7 @@ static void mesh_render_data_free(MeshRenderData *mr) MEM_SAFE_FREE(mr->loop_normals); MEM_SAFE_FREE(mr->lverts); - MEM_SAFE_FREE(mr->ledges); + //MEM_SAFE_FREE(mr->ledges); MEM_freeN(mr); } ``` @Jeroen-Bakker, does this have anything to do with recent changes to fix the wires drawing problem?
Collaborator

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

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

I can't reproduce the problem anymore.
I think this problem was related to the same problem described in #78004 (which was recently fixed).

A build with the fix will be available tomorrow.
Please check and confirm as soon as available: https://builder.blender.org/download/

I can't reproduce the problem anymore. I think this problem was related to the same problem described in #78004 (which was recently fixed). A build with the fix will be available tomorrow. Please check and confirm as soon as available: https://builder.blender.org/download/
Collaborator

Unfortunately I can now repro more reliably (without having to use Undo; but still involving tbb / threading) with latest master b89898cbd3. Here's the full crash report: blender.crash.txt

Stack trace:
blender.exe         :0x00007FF6387767B0  extract_pos_nor_loop_mesh F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:1597
blender.exe         :0x00007FF63877B7F0  extract_run F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:4708
blender.exe         :0x00007FF63877BE20  extract_single_threaded_task_node_exec F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:4804
tbb.dll             :0x00007FFBE25F51D0  tbb::interface7::internal::isolate_within_arena
blender.exe         :0x00007FF63E9B8BA0  tbb::interface7::internal::isolate_impl<void,<lambda_03c216e6db53fa8f9f63abfae8a04589> const > F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\task_arena.h:160
blender.exe         :0x00007FF63E9BA160  TaskNode::run F:\source\blender-git\blender\source\blender\blenlib\intern\task_graph.cc:98
blender.exe         :0x00007FF63E9B8640  std::_Call_binder<std::_Unforced,0,1,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.26.28801\include\functional:1415
blender.exe         :0x00007FF63E9B93C0  tbb::flow::interface11::internal::function_body_leaf<tbb::flow::interface11::continue_msg,tbb::flow F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\internal\_flow_graph_body_impl.h:147
blender.exe         :0x00007FF63E9B9B20  tbb::flow::interface11::internal::apply_body_task_bypass<tbb::flow::interface11::internal::continue F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\internal\_flow_graph_body_impl.h:312
tbb.dll             :0x00007FFBE26037A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FFBE26037A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FFBE25F51D0  tbb::interface7::internal::isolate_within_arena
tbb.dll             :0x00007FFBE25FA490  tbb::task_scheduler_init::terminate
tbb.dll             :0x00007FFBE26019C0  tbb::thread_bound_filter::try_process_item
tbb.dll             :0x00007FFBE26019C0  tbb::thread_bound_filter::try_process_item
Unfortunately I can now repro more reliably (without having to use Undo; but still involving tbb / threading) with latest master b89898cbd3. Here's the full crash report: [blender.crash.txt](https://archive.blender.org/developer/F8631012/blender.crash.txt) ``` Stack trace: blender.exe :0x00007FF6387767B0 extract_pos_nor_loop_mesh F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:1597 blender.exe :0x00007FF63877B7F0 extract_run F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:4708 blender.exe :0x00007FF63877BE20 extract_single_threaded_task_node_exec F:\source\blender-git\blender\source\blender\draw\intern\draw_cache_extract_mesh.c:4804 tbb.dll :0x00007FFBE25F51D0 tbb::interface7::internal::isolate_within_arena blender.exe :0x00007FF63E9B8BA0 tbb::interface7::internal::isolate_impl<void,<lambda_03c216e6db53fa8f9f63abfae8a04589> const > F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\task_arena.h:160 blender.exe :0x00007FF63E9BA160 TaskNode::run F:\source\blender-git\blender\source\blender\blenlib\intern\task_graph.cc:98 blender.exe :0x00007FF63E9B8640 std::_Call_binder<std::_Unforced,0,1,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.26.28801\include\functional:1415 blender.exe :0x00007FF63E9B93C0 tbb::flow::interface11::internal::function_body_leaf<tbb::flow::interface11::continue_msg,tbb::flow F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\internal\_flow_graph_body_impl.h:147 blender.exe :0x00007FF63E9B9B20 tbb::flow::interface11::internal::apply_body_task_bypass<tbb::flow::interface11::internal::continue F:\source\blender-git\lib\win64_vc15\tbb\include\tbb\internal\_flow_graph_body_impl.h:312 tbb.dll :0x00007FFBE26037A0 tbb::recursive_mutex::scoped_lock::internal_try_acquire tbb.dll :0x00007FFBE26037A0 tbb::recursive_mutex::scoped_lock::internal_try_acquire tbb.dll :0x00007FFBE25F51D0 tbb::interface7::internal::isolate_within_arena tbb.dll :0x00007FFBE25FA490 tbb::task_scheduler_init::terminate tbb.dll :0x00007FFBE26019C0 tbb::thread_bound_filter::try_process_item tbb.dll :0x00007FFBE26019C0 tbb::thread_bound_filter::try_process_item ```
Poster

Still getting the same crash with same Shift D, Alt D, Shift RRRRRRRRRR steps as before.
Using today's build (Windows) 6899cb3c07

Still getting the same crash with same Shift D, Alt D, Shift RRRRRRRRRR steps as before. Using today's build (Windows) 6899cb3c073e
Collaborator

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

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

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

Changed status from 'Needs Triage' to: 'Confirmed'
Poster

Also crashes when right clicking a collection in outliner > Instance to scene, then Shift D the newly instanced collection.
However does not crash when using Alt D on instanced collection

Also crashes when right clicking a collection in outliner > Instance to scene, then Shift D the newly instanced collection. However does not crash when using Alt D on instanced collection
jwun commented 3 years ago

Added subscriber: @jwun

Added subscriber: @jwun
Collaborator
Added subscribers: @FabianOrrego, @NanoGlyph, @xela_aklarts, @Alaska
Collaborator

Added subscribers: @VincentBlankfield, @antoniov

Added subscribers: @VincentBlankfield, @antoniov
Collaborator

Can someone retest this issue. There were several issues solved in this area and I ain't able to reproduce it. I also checked related tasks.

Can someone retest this issue. There were several issues solved in this area and I ain't able to reproduce it. I also checked related tasks.

Still reproducible in 2.90.0 Alpha, branch: master, commit date: 2020-07-13 15:08, hash: 29da019cb3

The condition of the assert from my merged report #78448 still fails. It's BLI_assert(mr->cache->surface_per_mat- [x]->elem == ibo) from extract_tris_finish in draw_cache_extract_mesh.c. It's condition fails reliably in release build whenever the Duplicate Linked (Alt+D) operation is performed. Tested only on Windows.

Was also able to reproduce the crash using steps from this report. Though for me the probability of reproducing it is and always have been about 0.001. The crash happened in extract_pos_nor_iter_poly_mesh of draw_cache_extract_mesh.c: vert->pos was NULL in copy_v3_v3(vert->pos, mv->co);.

Stack trace of thread 1 (crashed):

LINES=6
>	[Inline Frame] copy_v3_v3() Line 63	C

 	extract_pos_nor_iter_poly_mesh(mr=0x00000281e5abecc8, params, _data=0x00000281f258efd8) Line 1913	C
 	[Inline Frame] mesh_extract_iter(mr=0x00000281e5abecc8, iter_type=MR_ITER_POLY | MR_ITER_LEDGE | MR_ITER_LVERT, start=0, end=2147483647, extract=0x00007ff74c50f510, user_data=0x00000281f258efd8) Line 5130	C
 	extract_run(taskdata=0x00000281f1f41778) Line 5166	C
 	[Inline Frame] extract_init_and_run() Line 5187	C
 	extract_single_threaded_task_node_exec(task_data) Line 5261	C
 	[External Code]	
 	[Inline Frame] tbb::interface7::internal::isolate_impl() Line 160	C++
 	[Inline Frame] tbb::interface7::this_task_arena::isolate() Line 395	C++
 	TaskNode::run(UNUSED_input={...}) Line 97	C++
 	[Inline Frame] std::_Invoker_pmf_pointer::_Call() Line 146	C++
 	[Inline Frame] std::invoke() Line 146	C++
 	[Inline Frame] std::_Invoker_ret<std::_Unforced,0>::_Call() Line 146	C++
 	[Inline Frame] std::_Call_binder() Line 1858	C++
 	[Inline Frame] std::_Binder<std::_Unforced,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb::flow::interface11::continue_msg),TaskNode *,std::_Ph<1> const &>::operator()() Line 1914	C++
 	tbb::flow::interface11::internal::function_body_leaf<tbb::flow::interface11::continue_msg,tbb::flow::interface11::continue_msg,std::_Binder<std::_Unforced,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb::flow::interface11::continue_msg),TaskNode *,std::_Ph<1> const &> >::operator()(i) Line 147	C++
 	[Inline Frame] tbb::flow::interface11::internal::continue_input<tbb::flow::interface11::continue_msg,tbb::flow::interface11::internal::Policy<void> >::apply_body_bypass() Line 821	C++
 	tbb::flow::interface11::internal::apply_body_task_bypass<tbb::flow::interface11::internal::continue_input<tbb::flow::interface11::continue_msg,tbb::flow::interface11::internal::Policy<void> >,tbb::flow::interface11::continue_msg>::execute() Line 312	C++
 	[External Code]	

Stack trace of thread 2 (in parallel with the crashed one):

LINES=6
> 	[External Code]	

	[Inline Frame] gpu_uniformbuffer_update() Line 203	C
 	GPU_uniformbuffer_update(ubo=0x00000281f1c4a398, data=0x00000281f7132060) Line 210	C
 	workbench_update_material_ubos(UNUSED_wpd=0x00000281e5e67f38) Line 331	C
 	workbench_cache_finish(ved) Line 448	C
 	[Inline Frame] drw_engines_cache_finish() Line 1038	C
 	DRW_draw_render_loop_ex(depsgraph=0x00000281dc02b2b8, engine_type=0x00007ff74e1de6c0, region=0x00000281de0854e8, v3d=0x00000281de0861a8, viewport=0x00000281e5b87078, evil_C=0x00000281db51aef8) Line 1495	C
 	DRW_draw_view(C=0x00000281db51aef8) Line 1405	C
 	[Inline Frame] view3d_draw_view() Line 1608	C
 	view3d_main_region_draw(C=0x00000281db51aef8, region=0x00000281de0854e8) Line 1632	C
 	ED_region_do_draw(C=0x00000281db51aef8, region=0x00000281de0854e8) Line 543	C
 	wm_draw_window_offscreen(C=0x00000281db51aef8, win=0x00000281ddb7a668, stereo) Line 713	C
 	wm_draw_window(C=0x00000281db51aef8, win=0x00000281ddb7a668) Line 841	C
 	wm_draw_update(C=0x00000281db51aef8) Line 1042	C
 	WM_main(C=0x00000281db51aef8) Line 482	C
 	main(argc=1, UNUSED_argv_c=0x0000000000000000) Line 534	C
 	[External Code]	

Note: The line numbers for draw_cache_extract_mesh.c in the stack traces may be few lines off - that's because I added print statements to check the assert condition in the release build. Nothing else was changed.

Still reproducible in 2.90.0 Alpha, branch: master, commit date: 2020-07-13 15:08, hash: `29da019cb3` The condition of the assert from my merged report #78448 still fails. It's `BLI_assert(mr->cache->surface_per_mat- [x]->elem == ibo)` from `extract_tris_finish` in `draw_cache_extract_mesh.c`. It's condition fails reliably in release build whenever the Duplicate Linked (Alt+D) operation is performed. Tested only on Windows. Was also able to reproduce the crash using steps from this report. Though for me the probability of reproducing it is and always have been about 0.001. The crash happened in `extract_pos_nor_iter_poly_mesh` of `draw_cache_extract_mesh.c`: `vert->pos` was NULL in `copy_v3_v3(vert->pos, mv->co);`. Stack trace of thread 1 (crashed): ``` LINES=6 > [Inline Frame] copy_v3_v3() Line 63 C extract_pos_nor_iter_poly_mesh(mr=0x00000281e5abecc8, params, _data=0x00000281f258efd8) Line 1913 C [Inline Frame] mesh_extract_iter(mr=0x00000281e5abecc8, iter_type=MR_ITER_POLY | MR_ITER_LEDGE | MR_ITER_LVERT, start=0, end=2147483647, extract=0x00007ff74c50f510, user_data=0x00000281f258efd8) Line 5130 C extract_run(taskdata=0x00000281f1f41778) Line 5166 C [Inline Frame] extract_init_and_run() Line 5187 C extract_single_threaded_task_node_exec(task_data) Line 5261 C [External Code] [Inline Frame] tbb::interface7::internal::isolate_impl() Line 160 C++ [Inline Frame] tbb::interface7::this_task_arena::isolate() Line 395 C++ TaskNode::run(UNUSED_input={...}) Line 97 C++ [Inline Frame] std::_Invoker_pmf_pointer::_Call() Line 146 C++ [Inline Frame] std::invoke() Line 146 C++ [Inline Frame] std::_Invoker_ret<std::_Unforced,0>::_Call() Line 146 C++ [Inline Frame] std::_Call_binder() Line 1858 C++ [Inline Frame] std::_Binder<std::_Unforced,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb::flow::interface11::continue_msg),TaskNode *,std::_Ph<1> const &>::operator()() Line 1914 C++ tbb::flow::interface11::internal::function_body_leaf<tbb::flow::interface11::continue_msg,tbb::flow::interface11::continue_msg,std::_Binder<std::_Unforced,tbb::flow::interface11::continue_msg (__cdecl TaskNode::*)(tbb::flow::interface11::continue_msg),TaskNode *,std::_Ph<1> const &> >::operator()(i) Line 147 C++ [Inline Frame] tbb::flow::interface11::internal::continue_input<tbb::flow::interface11::continue_msg,tbb::flow::interface11::internal::Policy<void> >::apply_body_bypass() Line 821 C++ tbb::flow::interface11::internal::apply_body_task_bypass<tbb::flow::interface11::internal::continue_input<tbb::flow::interface11::continue_msg,tbb::flow::interface11::internal::Policy<void> >,tbb::flow::interface11::continue_msg>::execute() Line 312 C++ [External Code] ``` Stack trace of thread 2 (in parallel with the crashed one): ``` LINES=6 > [External Code] [Inline Frame] gpu_uniformbuffer_update() Line 203 C GPU_uniformbuffer_update(ubo=0x00000281f1c4a398, data=0x00000281f7132060) Line 210 C workbench_update_material_ubos(UNUSED_wpd=0x00000281e5e67f38) Line 331 C workbench_cache_finish(ved) Line 448 C [Inline Frame] drw_engines_cache_finish() Line 1038 C DRW_draw_render_loop_ex(depsgraph=0x00000281dc02b2b8, engine_type=0x00007ff74e1de6c0, region=0x00000281de0854e8, v3d=0x00000281de0861a8, viewport=0x00000281e5b87078, evil_C=0x00000281db51aef8) Line 1495 C DRW_draw_view(C=0x00000281db51aef8) Line 1405 C [Inline Frame] view3d_draw_view() Line 1608 C view3d_main_region_draw(C=0x00000281db51aef8, region=0x00000281de0854e8) Line 1632 C ED_region_do_draw(C=0x00000281db51aef8, region=0x00000281de0854e8) Line 543 C wm_draw_window_offscreen(C=0x00000281db51aef8, win=0x00000281ddb7a668, stereo) Line 713 C wm_draw_window(C=0x00000281db51aef8, win=0x00000281ddb7a668) Line 841 C wm_draw_update(C=0x00000281db51aef8) Line 1042 C WM_main(C=0x00000281db51aef8) Line 482 C main(argc=1, UNUSED_argv_c=0x0000000000000000) Line 534 C [External Code] ``` Note: The line numbers for `draw_cache_extract_mesh.c` in the stack traces may be few lines off - that's because I added print statements to check the assert condition in the release build. Nothing else was changed.
Jeroen-Bakker self-assigned this 3 years ago
Collaborator

I am able to reproduce on linux (release builds) using the repeat last action method. Thanks for the clarification!
I think that the reason why you cannot reproduce this in debug builds is that the threading method is synced to validate if every batch is created. During release mode this isn't the case and the sync is skipped. I will remove this section and see what is going on.

I am able to reproduce on linux (release builds) using the repeat last action method. Thanks for the clarification! I think that the reason why you cannot reproduce this in debug builds is that the threading method is synced to validate if every batch is created. During release mode this isn't the case and the sync is skipped. I will remove this section and see what is going on.
Collaborator

I have been looking into some alternatives to solve this issue.

Alternatives

Solution 1: Calculate single mesh/ob

diff --git a/source/blender/draw/intern/draw_cache_impl_mesh.c b/source/blender/draw/intern/draw_cache_impl_mesh.c
index e69fb795948..bb79df604c1 100644
--- a/source/blender/draw/intern/draw_cache_impl_mesh.c
+++ b/source/blender/draw/intern/draw_cache_impl_mesh.c
@@ -1536,12 +1536,12 @@ void DRW_mesh_batch_cache_create_requested(struct TaskGraph *task_graph,
                                      scene,
                                      ts,
                                      use_hide);
+  BLI_task_graph_work_and_wait(task_graph);
 #ifdef DEBUG
 check:
   /* Make sure all requested batches have been setup. */
   /* TODO(jbakker): we should move this to the draw_manager but that needs refactoring and
    * additional looping.*/
-  BLI_task_graph_work_and_wait(task_graph);
   for (int i = 0; i < sizeof(cache->batch) / sizeof(void *); i++) {
     BLI_assert(!DRW_batch_requested(((GPUBatch **)&cache->batch)[i], 0));
   }
  • + This fixes the issue
  • - but has a huge performance penalty. (02_020_A.anim.blend 12.5fps => 11fps)
  • - IBO's are throw away before any usage

Solution 2: Check for validity when extracting the IBO

  • - code not clean could lead to usage after free
  • - IBO's are throw away before any usage
  • - Can still fail due to threading issues, just less likely

Solution 3: Split DRW_mesh_batch_cache_create_requested

split DRW_mesh_batch_cache_create_requested so it only does (create requested). This means that it is only valid
to be called when all meshes are processed. Creates a GHash of all meshes and what needs to be done based on the
given object. schedule and start the extraction when all meshes have been checked.

NOTE: This could be optimized if we are 100% sure there is only a single user of the object. If that is the case there is
only a single object and we know that another object won't discard the IBO/VBO that are being calculated at that moment.

Solution 4: Combine Surface and Surface per material batch creation

Solution 3 would still work around the hack in the code-base. Solution 4 works on the idea that surface per material is most likely what users want. So why don't we combine the two batch creations so we could remove the hack.

NOTE: This solution could also add two fast paths for meshes with one or two materials.

I have been looking into some alternatives to solve this issue. # Alternatives ## Solution 1: Calculate single mesh/ob ``` diff --git a/source/blender/draw/intern/draw_cache_impl_mesh.c b/source/blender/draw/intern/draw_cache_impl_mesh.c index e69fb795948..bb79df604c1 100644 --- a/source/blender/draw/intern/draw_cache_impl_mesh.c +++ b/source/blender/draw/intern/draw_cache_impl_mesh.c @@ -1536,12 +1536,12 @@ void DRW_mesh_batch_cache_create_requested(struct TaskGraph *task_graph, scene, ts, use_hide); + BLI_task_graph_work_and_wait(task_graph); #ifdef DEBUG check: /* Make sure all requested batches have been setup. */ /* TODO(jbakker): we should move this to the draw_manager but that needs refactoring and * additional looping.*/ - BLI_task_graph_work_and_wait(task_graph); for (int i = 0; i < sizeof(cache->batch) / sizeof(void *); i++) { BLI_assert(!DRW_batch_requested(((GPUBatch **)&cache->batch)[i], 0)); } ``` * `+` This fixes the issue * `-` but has a huge performance penalty. (02_020_A.anim.blend 12.5fps => 11fps) * `-` IBO's are throw away before any usage ## Solution 2: Check for validity when extracting the IBO * `-` code not clean could lead to usage after free * `-` IBO's are throw away before any usage * `-` Can still fail due to threading issues, just less likely ## Solution 3: Split DRW_mesh_batch_cache_create_requested split DRW_mesh_batch_cache_create_requested so it only does (create requested). This means that it is only valid to be called when all meshes are processed. Creates a GHash of all meshes and what needs to be done based on the given object. schedule and start the extraction when all meshes have been checked. NOTE: This could be optimized if we are 100% sure there is only a single user of the object. If that is the case there is only a single object and we know that another object won't discard the IBO/VBO that are being calculated at that moment. ## Solution 4: Combine Surface and Surface per material batch creation Solution 3 would still work around the hack in the code-base. Solution 4 works on the idea that surface per material is most likely what users want. So why don't we combine the two batch creations so we could remove the hack. NOTE: This solution could also add two fast paths for meshes with one or two materials.
Owner

This issue was referenced by 9582797d4b

This issue was referenced by 9582797d4b50a18040e96ae07aa8c7643cbcc25a
Collaborator

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Jeroen-Bakker closed this issue 3 years ago
Collaborator

Added subscribers: @aleksijuvani, @lichtwerk

Added subscribers: @aleksijuvani, @lichtwerk
Sign in to join this conversation.
No Label
good first issue
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/2.81
legacy project/2.82
legacy project/2.83
legacy project/2.90
legacy project/2.91
legacy project/2.92
legacy project/3.0
legacy project/3.1
legacy project/3.2
legacy project/3.3
legacy project/Alembic
legacy project/Animation & Rigging
legacy project/Asset Browser
legacy project/Asset Browser (Archived)
legacy project/Asset Browser Project Overview
legacy project/Audio
legacy project/Automated Testing
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Blender Asset Bundle
legacy project/Code Quest
legacy project/Collada
legacy project/Compositing
legacy project/Core
legacy project/Cycles
legacy project/Datablocks and Libraries
legacy project/Dependency Graph
legacy project/Development Management
legacy project/Eevee
legacy project/EEVEE & Viewport
legacy project/Freestyle
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/Geometry Nodes
legacy project/Good First Issue
legacy project/GPU / Viewport
legacy project/Grease Pencil
legacy project/GSoC
legacy project/Images & Movies
legacy project/Import/Export
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Line Art
legacy project/Masking
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Modeling
legacy project/Modifiers
legacy project/Motion Tracking
legacy project/Nodes
legacy project/Nodes & Physics
legacy project/OpenGL Error
legacy project/Overrides
legacy project/Papercut
legacy project/Performance
legacy project/Physics
legacy project/Pipeline, Assets & I/O
legacy project/Platform: FreeBSD
legacy project/Platform: Linux
legacy project/Platform: macOS
legacy project/Platforms, Builds, Tests & Devices
legacy project/Platform: Windows
legacy project/Pose Library Basics
legacy project/Python API
legacy project/Render & Cycles
legacy project/Render Pipeline
legacy project/Retrospective
legacy project/Sculpt, Paint & Texture
legacy project/Text Editor
legacy project/Tracker Curfew
legacy project/Translations
legacy project/Triaging
legacy project/Undo
legacy project/USD
legacy project/User Interface
legacy project/UV Editing
legacy project/VFX & Video
legacy project/Video Sequencer
legacy project/Virtual Reality
legacy project/Wintab High Frequency
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › EEVEE & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds Tests & Devices
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Rendering & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
papercut
performance
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information from Developers
Status › Needs Information from User
Status › Needs Triage
Status › Resolved
Type › Bug
Type › Design
Type › Known Issue
Type › Patch
Type › Report
Type › To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#77867
Loading…
There is no content yet.