Regression: hide_set and hide_viewport on the same loop crash blender #102550

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.59

Blender Version
Broken: version: 3.4.0 Beta, branch: master, commit date: 2022-11-14 01:01, hash: blender/blender@0190b104c8
Worked: blender-3.4.0-alpha+master.788f3d72cf89-windows.amd64-release

Caused by blender/blender@09b9e1e95e

Short description of error
When you try to access to hide_set and hide_viewport properties of objects inside a collection inside the same for loop, blender crashes

Exact steps for others to reproduce the error
1- Open the provided test file
2- Look at the text editor script, there´s 2 for loops and on both of them, there´re lines commented

import bpy

#FIRST LOOP
for obj in bpy.data.collections["TEST"].all_objects:
#    obj.hide_set(True)
    obj.hide_viewport = True

#SECOND LOOP
for obj in bpy.data.collections["TEST"].all_objects:
    obj.hide_set(True)
#    obj.hide_viewport = True

3-If you execute the script, everything goes ok, objects will be hided on both methods, but it´s redundant to make it in two different loops
4-CTRL +Z to undo or revert the file
5-Now uncomment in any of the loops the line commented, in order to execute the two operations at once on the same for loop

import bpy

#FIRST LOOP
for obj in bpy.data.collections["TEST"].all_objects:
#    obj.hide_set(True)     <- UNCOMMENT THIS AND EXECUTE THE SCRIPT AGAIN, THE IT WILL CRASH
    obj.hide_viewport = True

#SECOND LOOP
for obj in bpy.data.collections["TEST"].all_objects:
    obj.hide_set(True)
#    obj.hide_viewport = True     <- OR UNCOMMENT THIS ONE EITHER

6-Blender crashes

hide_set_and_viewport_bug.blend

Added subscriber: @JVM

blender/blender#103611 was marked as duplicate of this issue

Added subscriber: @deadpin

Due to how Collections are implemented, setting certain fields like hide_viewport is problematic. This particular case is so surprising we had to specifically document it a few years back: https://docs.blender.org/api/master/info_gotcha.html#unfortunate-corner-cases

Create a copy of the .all_objects list and use the copy for iteration.

Mmm i see.
Workaround is always good, but still a bug anyway @deadpin

Yeah, I filed the original blender/blender#62406 bug

Thanks buddy :)

Added subscriber: @lichtwerk

@deadpin: but is it expected to crash? @JVM also mentioned it didnt crash in blender/blender@788f3d72cf

Ah. If it started working that is news to me and it would be great to solve actually :) I didn't fight the original bug's closure way back when but as far as I knew it's been crashy since the beginning.

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

Crash indeed seems like a regression, will check on this...

Added subscriber: @Sergey

Caused by blender/blender@09b9e1e95e

@Sergey: I am aware of https://docs.blender.org/api/master/info_gotcha.html#unfortunate-corner-cases, but crash is a regression, mind checking?

1   rna_ID_refine                                    rna_ID.c             568  0x184ae6b 
2   rna_pointer_inherit_refine                       rna_access.c         195  0x1832a13 
3   rna_Collection_all_objects_get                   rna_collection.c     65   0x1888cb0 
4   Collection_all_objects_get                       rna_collection_gen.c 193  0x1889b30 
5   Collection_all_objects_next                      rna_collection_gen.c 215  0x1889c1f 
6   RNA_property_collection_next                     rna_access.c         3721 0x183bc31 
7   pyrna_prop_collection_iter_next                  bpy_rna.c            7037 0x1ac6211 
8   _PyEval_EvalFrameDefault                         ceval.c              4001 0x798227  
9   _PyEval_EvalFrame                                pycore_ceval.h       46   0xfa660cc 
10  _PyEval_Vector                                   ceval.c              5065 0xfa660cc 
11  PyEval_EvalCode                                  ceval.c              1134 0xfa660cc 
12  python_script_exec                               bpy_interface_run.c  137  0x1aaee98 
13  BPY_run_text                                     bpy_interface_run.c  234  0x1aaf0e4 
14  text_run_script                                  text_ops.c           775  0x2b1cf38 
15  text_run_script_exec                             text_ops.c           812  0x2b1cff2 
16  wm_operator_invoke                               wm_event_system.cc   1456 0x11b9b11 
17  wm_operator_call_internal                        wm_event_system.cc   1650 0x11ba17b 
18  WM_operator_name_call_ptr                        wm_event_system.cc   1698 0x11ba37c 
19  WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc   1891 0x11ba948 
20  ui_apply_but_funcs_after                         interface_handlers.c 1018 0x273c53d 
... <More>

Caused by blender/blender@09b9e1e95e @Sergey: I am aware of https://docs.blender.org/api/master/info_gotcha.html#unfortunate-corner-cases, but crash is a regression, mind checking? ``` 1 rna_ID_refine rna_ID.c 568 0x184ae6b 2 rna_pointer_inherit_refine rna_access.c 195 0x1832a13 3 rna_Collection_all_objects_get rna_collection.c 65 0x1888cb0 4 Collection_all_objects_get rna_collection_gen.c 193 0x1889b30 5 Collection_all_objects_next rna_collection_gen.c 215 0x1889c1f 6 RNA_property_collection_next rna_access.c 3721 0x183bc31 7 pyrna_prop_collection_iter_next bpy_rna.c 7037 0x1ac6211 8 _PyEval_EvalFrameDefault ceval.c 4001 0x798227 9 _PyEval_EvalFrame pycore_ceval.h 46 0xfa660cc 10 _PyEval_Vector ceval.c 5065 0xfa660cc 11 PyEval_EvalCode ceval.c 1134 0xfa660cc 12 python_script_exec bpy_interface_run.c 137 0x1aaee98 13 BPY_run_text bpy_interface_run.c 234 0x1aaf0e4 14 text_run_script text_ops.c 775 0x2b1cf38 15 text_run_script_exec text_ops.c 812 0x2b1cff2 16 wm_operator_invoke wm_event_system.cc 1456 0x11b9b11 17 wm_operator_call_internal wm_event_system.cc 1650 0x11ba17b 18 WM_operator_name_call_ptr wm_event_system.cc 1698 0x11ba37c 19 WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc 1891 0x11ba948 20 ui_apply_but_funcs_after interface_handlers.c 1018 0x273c53d ... <More> ```

@lichtwerk In both cases (before and after my change) this is a heap-use-after-free issue: P3317: (An Untitled Masterwork)

Read blend: /Users/sergey/Downloads/hide_set_and_viewport_bug.blend
=================================================================
==12465==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000216d48 at pc 0x00010d2c8f05 bp 0x7ff7b9fde760 sp 0x7ff7b9fde758
READ of size 8 at 0x606000216d48 thread T0
    #0 0x10d2c8f04 in rna_iterator_listbase_next rna_access.c:4734
    #1 0x10d45e8b9 in Collection_all_objects_next rna_collection_gen.c:212
    #2 0x10d283787 in RNA_property_collection_next rna_access.c:3721
    #3 0x10e1814df in pyrna_prop_collection_iter_next bpy_rna.c:7224
    #4 0x142cb0f35 in _PyEval_EvalFrameDefault ceval.c:4001
    #5 0x142ca9da0 in _PyEval_Vector ceval.c:5065
    #6 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134
    #7 0x10e115dbd in python_script_exec bpy_interface_run.c:137
    #8 0x10e116b73 in BPY_run_text bpy_interface_run.c:234
    #9 0x1152a57ac in text_run_script text_ops.c:775
    #10 0x1152a55d8 in text_run_script_exec text_ops.c:812
    #11 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455
    #12 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649
    #13 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697
    #14 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890
    #15 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018
    #16 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402
    #17 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786
    #18 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217
    #19 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334
    #20 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925
    #21 0x10a8c5676 in WM_main wm.c:640
    #22 0x1060b51a2 in main creator.c:575
    #23 0x7ff80983830f  (<unknown module>)

0x606000216d48 is located 8 bytes inside of 56-byte region [0x606000216d40,0x606000216d78)
freed by thread T0 here:
    #0 0x190240019 in wrap_free+0xa9 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4b019)
    #1 0x1426a50eb in MEM_lockfree_freeN mallocn_lockfree_impl.c:117
    #2 0x141f1a5ed in BLI_freelistN listbase.c:473
    #3 0x10650ca93 in collection_object_cache_free collection.c:849
    #4 0x1065055d4 in BKE_collection_object_cache_free collection.c:859
    #5 0x10773ac89 in BKE_main_collection_sync_remap layer.c:1439
    #6 0x10db08af0 in rna_Object_hide_update rna_object.c:367
    #7 0x10d296e90 in rna_property_update rna_access.c:2071
    #8 0x10d2969a9 in RNA_property_update rna_access.c:2140
    #9 0x10e15c4e3 in pyrna_py_to_prop bpy_rna.c:2087
    #10 0x10e161956 in pyrna_struct_setattro bpy_rna.c:4551
    #11 0x142c09eab in PyObject_SetAttr object.c:1044
    #12 0x142cad46b in _PyEval_EvalFrameDefault ceval.c:2850
    #13 0x142ca9da0 in _PyEval_Vector ceval.c:5065
    #14 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134
    #15 0x10e115dbd in python_script_exec bpy_interface_run.c:137
    #16 0x10e116b73 in BPY_run_text bpy_interface_run.c:234
    #17 0x1152a57ac in text_run_script text_ops.c:775
    #18 0x1152a55d8 in text_run_script_exec text_ops.c:812
    #19 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455
    #20 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649
    #21 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697
    #22 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890
    #23 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018
    #24 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402
    #25 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786
    #26 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217
    #27 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334
    #28 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925
    #29 0x10a8c5676 in WM_main wm.c:640

previously allocated by thread T0 here:
    #0 0x1902402a5 in wrap_calloc+0xa5 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4b2a5)
    #1 0x1426a6774 in MEM_lockfree_callocN mallocn_lockfree_impl.c:223
    #2 0x10650bbea in collection_object_cache_fill collection.c:787
    #3 0x10650b7d7 in BKE_collection_object_cache_get collection.c:819
    #4 0x10d45e51c in rna_Collection_all_objects_begin rna_collection.c:55
    #5 0x10d45e216 in Collection_all_objects_begin rna_collection_gen.c:203
    #6 0x10d282f61 in RNA_property_collection_begin rna_access.c:3705
    #7 0x10e1812d6 in pyrna_prop_collection_iter_CreatePyObject bpy_rna.c:7193
    #8 0x10e17b7ba in pyrna_prop_collection_iter bpy_rna.c:7200
    #9 0x142ba62d7 in PyObject_GetIter abstract.c:2813
    #10 0x142cb0e04 in _PyEval_EvalFrameDefault ceval.c:3958
    #11 0x142ca9da0 in _PyEval_Vector ceval.c:5065
    #12 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134
    #13 0x10e115dbd in python_script_exec bpy_interface_run.c:137
    #14 0x10e116b73 in BPY_run_text bpy_interface_run.c:234
    #15 0x1152a57ac in text_run_script text_ops.c:775
    #16 0x1152a55d8 in text_run_script_exec text_ops.c:812
    #17 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455
    #18 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649
    #19 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697
    #20 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890
    #21 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018
    #22 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402
    #23 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786
    #24 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217
    #25 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334
    #26 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925
    #27 0x10a8c5676 in WM_main wm.c:640
    #28 0x1060b51a2 in main creator.c:575
    #29 0x7ff80983830f  (<unknown module>)

SUMMARY: AddressSanitizer: heap-use-after-free rna_access.c:4734 in rna_iterator_listbase_next
Shadow bytes around the buggy address:
  0x1c0c00042d50: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x1c0c00042d60: fd fd fd fd fd fd fd fa fa fa fa fa 00 00 00 00
  0x1c0c00042d70: 00 00 00 00 fa fa fa fa fd fd fd fd fd fd fd fa
  0x1c0c00042d80: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x1c0c00042d90: 00 00 00 00 00 00 00 00 fa fa fa fa fd fd fd fd
=>0x1c0c00042da0: fd fd fd fa fa fa fa fa fd[fd]fd fd fd fd fd fa
  0x1c0c00042db0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x1c0c00042dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0c00042dd0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c0c00042de0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x1c0c00042df0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==12465==ABORTING
zsh: abort      ./bin/Blender.app/Contents/MacOS/Blender

Is just the change exposed the wrong memory access which has already been happening before.

Perhaps something like all_objects = bpy.data.collections["TEST"].all_objects- [x]; for object in all_objects: ... will lead to the desired result.

And i am not really sure if or how we can prevent crash when the content of collection changes in the loop. Also, don't really see this mentioned in the corner cases page.

@lichtwerk In both cases (before and after my change) this is a heap-use-after-free issue: [P3317: (An Untitled Masterwork)](https://archive.blender.org/developer/P3317.txt) ``` Read blend: /Users/sergey/Downloads/hide_set_and_viewport_bug.blend ================================================================= ==12465==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000216d48 at pc 0x00010d2c8f05 bp 0x7ff7b9fde760 sp 0x7ff7b9fde758 READ of size 8 at 0x606000216d48 thread T0 #0 0x10d2c8f04 in rna_iterator_listbase_next rna_access.c:4734 #1 0x10d45e8b9 in Collection_all_objects_next rna_collection_gen.c:212 #2 0x10d283787 in RNA_property_collection_next rna_access.c:3721 #3 0x10e1814df in pyrna_prop_collection_iter_next bpy_rna.c:7224 #4 0x142cb0f35 in _PyEval_EvalFrameDefault ceval.c:4001 #5 0x142ca9da0 in _PyEval_Vector ceval.c:5065 #6 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134 #7 0x10e115dbd in python_script_exec bpy_interface_run.c:137 #8 0x10e116b73 in BPY_run_text bpy_interface_run.c:234 #9 0x1152a57ac in text_run_script text_ops.c:775 #10 0x1152a55d8 in text_run_script_exec text_ops.c:812 #11 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455 #12 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649 #13 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697 #14 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890 #15 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018 #16 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402 #17 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786 #18 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217 #19 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334 #20 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925 #21 0x10a8c5676 in WM_main wm.c:640 #22 0x1060b51a2 in main creator.c:575 #23 0x7ff80983830f (<unknown module>) 0x606000216d48 is located 8 bytes inside of 56-byte region [0x606000216d40,0x606000216d78) freed by thread T0 here: #0 0x190240019 in wrap_free+0xa9 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4b019) #1 0x1426a50eb in MEM_lockfree_freeN mallocn_lockfree_impl.c:117 #2 0x141f1a5ed in BLI_freelistN listbase.c:473 #3 0x10650ca93 in collection_object_cache_free collection.c:849 #4 0x1065055d4 in BKE_collection_object_cache_free collection.c:859 #5 0x10773ac89 in BKE_main_collection_sync_remap layer.c:1439 #6 0x10db08af0 in rna_Object_hide_update rna_object.c:367 #7 0x10d296e90 in rna_property_update rna_access.c:2071 #8 0x10d2969a9 in RNA_property_update rna_access.c:2140 #9 0x10e15c4e3 in pyrna_py_to_prop bpy_rna.c:2087 #10 0x10e161956 in pyrna_struct_setattro bpy_rna.c:4551 #11 0x142c09eab in PyObject_SetAttr object.c:1044 #12 0x142cad46b in _PyEval_EvalFrameDefault ceval.c:2850 #13 0x142ca9da0 in _PyEval_Vector ceval.c:5065 #14 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134 #15 0x10e115dbd in python_script_exec bpy_interface_run.c:137 #16 0x10e116b73 in BPY_run_text bpy_interface_run.c:234 #17 0x1152a57ac in text_run_script text_ops.c:775 #18 0x1152a55d8 in text_run_script_exec text_ops.c:812 #19 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455 #20 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649 #21 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697 #22 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890 #23 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018 #24 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402 #25 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786 #26 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217 #27 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334 #28 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925 #29 0x10a8c5676 in WM_main wm.c:640 previously allocated by thread T0 here: #0 0x1902402a5 in wrap_calloc+0xa5 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4b2a5) #1 0x1426a6774 in MEM_lockfree_callocN mallocn_lockfree_impl.c:223 #2 0x10650bbea in collection_object_cache_fill collection.c:787 #3 0x10650b7d7 in BKE_collection_object_cache_get collection.c:819 #4 0x10d45e51c in rna_Collection_all_objects_begin rna_collection.c:55 #5 0x10d45e216 in Collection_all_objects_begin rna_collection_gen.c:203 #6 0x10d282f61 in RNA_property_collection_begin rna_access.c:3705 #7 0x10e1812d6 in pyrna_prop_collection_iter_CreatePyObject bpy_rna.c:7193 #8 0x10e17b7ba in pyrna_prop_collection_iter bpy_rna.c:7200 #9 0x142ba62d7 in PyObject_GetIter abstract.c:2813 #10 0x142cb0e04 in _PyEval_EvalFrameDefault ceval.c:3958 #11 0x142ca9da0 in _PyEval_Vector ceval.c:5065 #12 0x142ca9cf0 in PyEval_EvalCode ceval.c:1134 #13 0x10e115dbd in python_script_exec bpy_interface_run.c:137 #14 0x10e116b73 in BPY_run_text bpy_interface_run.c:234 #15 0x1152a57ac in text_run_script text_ops.c:775 #16 0x1152a55d8 in text_run_script_exec text_ops.c:812 #17 0x10a90d2c1 in wm_operator_invoke(bContext*, wmOperatorType*, wmEvent const*, PointerRNA*, ReportList*, bool, bool) wm_event_system.cc:1455 #18 0x10a90b6c0 in wm_operator_call_internal(bContext*, wmOperatorType*, PointerRNA*, ReportList*, wmOperatorCallContext, bool, wmEvent const*) wm_event_system.cc:1649 #19 0x10a9157ae in WM_operator_name_call_ptr wm_event_system.cc:1697 #20 0x10a916620 in WM_operator_name_call_ptr_with_depends_on_cursor wm_event_system.cc:1890 #21 0x113ae751e in ui_apply_but_funcs_after interface_handlers.c:1018 #22 0x113acae5d in ui_handler_region_menu interface_handlers.c:11402 #23 0x10a931350 in wm_handler_ui_call(bContext*, wmEventHandler_UI*, wmEvent const*, int) wm_event_system.cc:786 #24 0x10a92d338 in wm_handlers_do_intern(bContext*, wmWindow*, wmEvent*, ListBase*) wm_event_system.cc:3217 #25 0x10a92372a in wm_handlers_do(bContext*, wmEvent*, ListBase*) wm_event_system.cc:3334 #26 0x10a920087 in wm_event_do_handlers wm_event_system.cc:3925 #27 0x10a8c5676 in WM_main wm.c:640 #28 0x1060b51a2 in main creator.c:575 #29 0x7ff80983830f (<unknown module>) SUMMARY: AddressSanitizer: heap-use-after-free rna_access.c:4734 in rna_iterator_listbase_next Shadow bytes around the buggy address: 0x1c0c00042d50: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x1c0c00042d60: fd fd fd fd fd fd fd fa fa fa fa fa 00 00 00 00 0x1c0c00042d70: 00 00 00 00 fa fa fa fa fd fd fd fd fd fd fd fa 0x1c0c00042d80: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x1c0c00042d90: 00 00 00 00 00 00 00 00 fa fa fa fa fd fd fd fd =>0x1c0c00042da0: fd fd fd fa fa fa fa fa fd[fd]fd fd fd fd fd fa 0x1c0c00042db0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x1c0c00042dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0c00042dd0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x1c0c00042de0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x1c0c00042df0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==12465==ABORTING zsh: abort ./bin/Blender.app/Contents/MacOS/Blender ``` Is just the change exposed the wrong memory access which has already been happening before. Perhaps something like `all_objects = bpy.data.collections["TEST"].all_objects- [x]; for object in all_objects: ...` will lead to the desired result. And i am not really sure if or how we can prevent crash when the content of collection changes in the loop. Also, don't really see this mentioned in the corner cases page.

In #102550#1446955, @Sergey wrote:
@lichtwerk In both cases (before and after my change) this is a heap-use-after-free issue:
Is just the change exposed the wrong memory access which has already been happening before.

Thx checking

Perhaps something like all_objects = bpy.data.collections["TEST"].all_objects- [x]; for object in all_objects: ... will lead to the desired result.

Yep, this indeed has no issues (should have tried that myself)

And i am not really sure if or how we can prevent crash when the content of collection changes in the loop. Also, don't really see this mentioned in the corner cases page.

"breaking any current iteration over Collection.all_objects" is something that is happening here (just not clear that this includes crashes)
So maybe we can put the above workaround in the documentation and call this done?

breaking any current iteration over Collection.all_objects" is something that is happening here (just not clear that this includes crashes)

Somehow I've managed to miss that sentence yesterday.

So maybe we can put the above workaround in the documentation and call this done?

I think that could be good.

Added subscriber: @monique

Had a quick look at this issue. Here are my findings:

The hide_set syncs the viewlayer when it's flagged out-of-sync and tags the viewlayer out of sync at the end because the base->flag (HIDDEN) has been modified
The hide_viewport flags the viewlayer out of sync and frees all caches (basically it calls for a full remap: BKE_main_collection_sync_remap ).

So in the loop, when hide_set tries to sync I suspect that the iterator is pointing to unallocated memory, because of the full syncing in hide_viewport.
It is unclear to me how the iterator "gets updated" when caches/memory get freed during the full sync.

Added subscriber: @Blendify

@Blendify : could you add that? ^^

Added subscriber: @mont29

Will update the doc. Note that using - [x] syntax is enough, no need to explicitly store the list copy:

for object in bpy.data.collections["TEST"].all_objects[:]:

Changed status from 'Confirmed' to: 'Archived'

Added subscriber: @reed2000

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: hide_set and hide_viewport on the same loop crash blender #102550