Regression: Attempt to move object with Copy Location (with Offset) crashes #111120

Open
opened 2023-08-14 18:30:34 +02:00 by James Tomkinson · 15 comments

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.67

Blender Version
Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-10-13 23:21, hash: rB1fbd300adb9a
Worked: version: 3.4.0 Alpha, branch: master, commit date: 2022-10-13 00:16, hash: rBb3e6a2888a2d

Short description of error
A consistent crash when trying to move an object with COPY LOC w/ Offset enabled.

Exact steps for others to reproduce the error

  1. Open the attached blend file

  2. Move the pre-selected object in any direction, you may have to do this two or three times

  3. program will crash with EXCEPTION_ACCESS_VIOLATION

This is happening every time.

Stack trace:
blender.exe         :0x00007FF73E03C510  blender::bounds::min_max<blender::VecBase<float,3> >
blender.exe         :0x00007FF73E03BD30  blender::FunctionRef<void __cdecl(blender::Bounds<blender::VecBase<float,3> > &)>::callback_fn<<lam
tbb.dll             :0x00007FF9998C4FD0  tbb::interface7::internal::isolate_within_arena
blender.exe         :0x00007FF7425212F0  blender::CacheMutex::ensure
blender.exe         :0x00007FF73E042390  BKE_mesh_minmax
blender.exe         :0x00007FF73E0409F0  BKE_mesh_boundbox_get
blender.exe         :0x00007FF73E02E940  BKE_object_boundbox_get
blender.exe         :0x00007FF73E02F410  BKE_object_dimensions_get
blender.exe         :0x00007FF73E613520  RNA_property_float_get_index
blender.exe         :0x00007FF73E235050  dtar_get_prop_val
blender.exe         :0x00007FF73E235410  evaluate_driver
blender.exe         :0x00007FF73E168590  calculate_fcurve
blender.exe         :0x00007FF73E156270  BKE_animsys_eval_driver
blender.exe         :0x00007FF73E4464F0  blender::deg::`anonymous namespace'::evaluate_node
blender.exe         :0x00007FF73E446320  blender::deg::`anonymous namespace'::deg_task_run_func
blender.exe         :0x00007FF7425175C0  tbb::internal::function_task<Task>::execute
tbb.dll             :0x00007FF9998CF220  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FF9998CF220  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FF9998C4FD0  tbb::interface7::internal::isolate_within_arena
tbb.dll             :0x00007FF9998CA120  tbb::task_scheduler_init::terminate
tbb.dll             :0x00007FF9998CD800  tbb::thread_bound_filter::try_process_item
tbb.dll             :0x00007FF9998CD800  tbb::thread_bound_filter::try_process_item
ucrtbase.dll        :0x00007FF9A5D192C0  recalloc
KERNEL32.DLL        :0x00007FF9A6F72690  BaseThreadInitThunk
ntdll.dll           :0x00007FF9A882AA40  RtlUserThreadStart
**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.67 **Blender Version** Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-10-13 23:21, hash: `rB1fbd300adb9a` Worked: version: 3.4.0 Alpha, branch: master, commit date: 2022-10-13 00:16, hash: `rBb3e6a2888a2d` **Short description of error** A consistent crash when trying to move an object with COPY LOC w/ Offset enabled. **Exact steps for others to reproduce the error** 1. Open the attached blend file 2. Move the pre-selected object in any direction, you may have to do this two or three times 3. program will crash with EXCEPTION_ACCESS_VIOLATION This is happening every time. ``` Stack trace: blender.exe :0x00007FF73E03C510 blender::bounds::min_max<blender::VecBase<float,3> > blender.exe :0x00007FF73E03BD30 blender::FunctionRef<void __cdecl(blender::Bounds<blender::VecBase<float,3> > &)>::callback_fn<<lam tbb.dll :0x00007FF9998C4FD0 tbb::interface7::internal::isolate_within_arena blender.exe :0x00007FF7425212F0 blender::CacheMutex::ensure blender.exe :0x00007FF73E042390 BKE_mesh_minmax blender.exe :0x00007FF73E0409F0 BKE_mesh_boundbox_get blender.exe :0x00007FF73E02E940 BKE_object_boundbox_get blender.exe :0x00007FF73E02F410 BKE_object_dimensions_get blender.exe :0x00007FF73E613520 RNA_property_float_get_index blender.exe :0x00007FF73E235050 dtar_get_prop_val blender.exe :0x00007FF73E235410 evaluate_driver blender.exe :0x00007FF73E168590 calculate_fcurve blender.exe :0x00007FF73E156270 BKE_animsys_eval_driver blender.exe :0x00007FF73E4464F0 blender::deg::`anonymous namespace'::evaluate_node blender.exe :0x00007FF73E446320 blender::deg::`anonymous namespace'::deg_task_run_func blender.exe :0x00007FF7425175C0 tbb::internal::function_task<Task>::execute tbb.dll :0x00007FF9998CF220 tbb::recursive_mutex::scoped_lock::internal_try_acquire tbb.dll :0x00007FF9998CF220 tbb::recursive_mutex::scoped_lock::internal_try_acquire tbb.dll :0x00007FF9998C4FD0 tbb::interface7::internal::isolate_within_arena tbb.dll :0x00007FF9998CA120 tbb::task_scheduler_init::terminate tbb.dll :0x00007FF9998CD800 tbb::thread_bound_filter::try_process_item tbb.dll :0x00007FF9998CD800 tbb::thread_bound_filter::try_process_item ucrtbase.dll :0x00007FF9A5D192C0 recalloc KERNEL32.DLL :0x00007FF9A6F72690 BaseThreadInitThunk ntdll.dll :0x00007FF9A882AA40 RtlUserThreadStart ```
James Tomkinson added the
Type
Report
Priority
Normal
Status
Needs Triage
labels 2023-08-14 18:30:35 +02:00
Iliya Katushenock changed title from Attempt to move object with Copy Locatioh (with Offset) crashes to Regression: Attempt to move object with Copy Locatioh (with Offset) crashes 2023-08-14 18:34:04 +02:00

I'll check.

I'll check.

update, while this happens consistently on the reporting platform, it doesn't happen on:

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.67

update, while this happens consistently on the reporting platform, it doesn't happen on: **System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.67
James Tomkinson changed title from Regression: Attempt to move object with Copy Locatioh (with Offset) crashes to Regression: Attempt to move object with Copy Location (with Offset) crashes 2023-08-14 18:38:57 +02:00

Thanks for report. I can confirm bug, but also i can see dependency cycle in terminal:

Dependency cycle detected:
  OBLouver.small.004/DIMENSIONS() depends on
  OBLouver.small.004/GEOMETRY_EVAL() via 'Geometry -> Dimensions'
  OBLouver.small.004/MODIFIER(Array) via 'modifier stack order'
  OBLouver.small.004/GEOMETRY_EVAL_INIT() via 'Modifier'
  OBLouver.small.004/DRIVER(modifiers["Array"].constant_offset_displace) via 'Driver -> Driven Property'
  OBLouver.small.004/DIMENSIONS() via 'RNA Target -> Driver'
Dependency cycle detected:
  OBLouver.small.001/DIMENSIONS() depends on
  OBLouver.small.001/GEOMETRY_EVAL() via 'Geometry -> Dimensions'
  OBLouver.small.001/MODIFIER(Array) via 'modifier stack order'
  OBLouver.small.001/GEOMETRY_EVAL_INIT() via 'Modifier'
  OBLouver.small.001/DRIVER(modifiers["Array"].constant_offset_displace) via 'Driver -> Driven Property'
  OBLouver.small.001/DIMENSIONS() via 'RNA Target -> Driver'
Detected 2 dependency cycles

This is undefined behavior. If i delete both objects, i unable to reproduce crash anymore.
Can you fix your project to avoid cycles and confirm fix of crash?

Thanks for report. I can confirm bug, but also i can see dependency cycle in terminal: ``` Dependency cycle detected: OBLouver.small.004/DIMENSIONS() depends on OBLouver.small.004/GEOMETRY_EVAL() via 'Geometry -> Dimensions' OBLouver.small.004/MODIFIER(Array) via 'modifier stack order' OBLouver.small.004/GEOMETRY_EVAL_INIT() via 'Modifier' OBLouver.small.004/DRIVER(modifiers["Array"].constant_offset_displace) via 'Driver -> Driven Property' OBLouver.small.004/DIMENSIONS() via 'RNA Target -> Driver' Dependency cycle detected: OBLouver.small.001/DIMENSIONS() depends on OBLouver.small.001/GEOMETRY_EVAL() via 'Geometry -> Dimensions' OBLouver.small.001/MODIFIER(Array) via 'modifier stack order' OBLouver.small.001/GEOMETRY_EVAL_INIT() via 'Modifier' OBLouver.small.001/DRIVER(modifiers["Array"].constant_offset_displace) via 'Driver -> Driven Property' OBLouver.small.001/DIMENSIONS() via 'RNA Target -> Driver' Detected 2 dependency cycles ``` This is undefined behavior. If i delete both objects, i unable to reproduce crash anymore. Can you fix your project to avoid cycles and confirm fix of crash?

Because I don't know how to fix the dependency cycle, I just deleted the driver and will adjust these variables manually. Yes: it no longer crashes.

I also notice that the driver editor window sometimes cannot be closed if I leave it alone for a coffee break, unless I switch to another app and back again. Perhaps I'll switch to decaf? ;)

Because I don't know how to fix the dependency cycle, I just deleted the driver and will adjust these variables manually. Yes: it no longer crashes. I also notice that the driver editor window sometimes cannot be closed if I leave it alone for a coffee break, unless I switch to another app and back again. Perhaps I'll switch to decaf? ;)
Blender Bot added
Status
Archived
and removed
Status
Needs Information from User
labels 2023-08-14 20:43:04 +02:00
Member

Talked to @Sergey in chat, dependency cycles can lead to undefined behavior, however, these should not crash, will reopen...

Talked to @Sergey in chat, dependency cycles can lead to undefined behavior, however, these should not crash, will reopen...
Blender Bot added
Status
Needs Triage
and removed
Status
Archived
labels 2023-08-15 09:30:07 +02:00
Member

Additional ASAN info:

==199382==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b00020d9f8 at pc 0x000001273d1c bp 0x7f891f442b80 sp 0x7f891f442b78
READ of size 4 at 0x60b00020d9f8 thread T69
    #0 0x1273d1b in BKE_object_dimensions_get /blender/source/blender/blenkernel/intern/object.cc:3853
    #1 0x69a80c2 in rna_Object_dimensions_get /blender/source/blender/makesrna/intern/rna_object.cc:1227
    #2 0x69b84de in Object_dimensions_get /build_linux_debug/source/blender/makesrna/intern/rna_object_gen.cc:807
    #3 0x631feff in RNA_property_float_get_array(PointerRNA*, PropertyRNA*, float*) /blender/source/blender/makesrna/intern/rna_access.cc:3063
    #4 0x6320c19 in RNA_property_float_get_index(PointerRNA*, PropertyRNA*, int) /blender/source/blender/makesrna/intern/rna_access.cc:3121
    #5 0x356afd7 in dtar_get_prop_val /blender/source/blender/blenkernel/intern/fcurve_driver.cc:226
    #6 0x356c977 in dvar_eval_singleProp /blender/source/blender/blenkernel/intern/fcurve_driver.cc:359
    #7 0x357464c in driver_get_variable_value /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1244
    #8 0x357498a in evaluate_driver_sum /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1262
    #9 0x3575491 in evaluate_driver /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1363
    #10 0x35651eb in evaluate_fcurve_driver /blender/source/blender/blenkernel/intern/fcurve.cc:2358
    #11 0x3565774 in calculate_fcurve /blender/source/blender/blenkernel/intern/fcurve.cc:2412
    #12 0x30e9da2 in BKE_animsys_eval_driver /blender/source/blender/blenkernel/intern/anim_sys.cc:4187
    #13 0x50b5b2b in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1270
    #14 0x50f0856 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_driver(ID*, FCurve*, int)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61
    #15 0x50e813c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_driver(ID*, FCurve*, int)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111
    #16 0x50e093f in _M_invoke /usr/include/c++/12/bits/std_function.h:290
    #17 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591
    #18 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102
    #19 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119
    #20 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166
    #21 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059
    #22 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44)
    #23 0x7f8970e42e77 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) (/build_linux_debug/bin/lib/libtbb.so.2+0x29e77)
    #24 0x7f8970e2b756 in tbb::internal::arena::process(tbb::internal::generic_scheduler&) (/build_linux_debug/bin/lib/libtbb.so.2+0x12756)
    #25 0x7f8970e39abf in tbb::internal::market::process(rml::job&) (/build_linux_debug/bin/lib/libtbb.so.2+0x20abf)
    #26 0x7f8970e3d59b in tbb::internal::rml::private_worker::run() (/build_linux_debug/bin/lib/libtbb.so.2+0x2459b)
    #27 0x7f8970e3d7d8 in tbb::internal::rml::private_worker::thread_routine(void*) (/build_linux_debug/bin/lib/libtbb.so.2+0x247d8)
    #28 0x7f8966cae12c in start_thread (/lib64/libc.so.6+0x8b12c)
    #29 0x7f8966d2fbbf in __clone3 (/lib64/libc.so.6+0x10cbbf)

0x60b00020d9f8 is located 56 bytes inside of 112-byte region [0x60b00020d9c0,0x60b00020da30)
freed by thread T0 here:
    #0 0x7f89706b9388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388)
    #1 0x4277ea3 in MEM_lockfree_freeN /blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:104
    #2 0x1258e5f in BKE_object_free_derived_caches /blender/source/blender/blenkernel/intern/object.cc:1794
    #3 0x306cf56 in makeDerivedMesh /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1550
    #4 0x12cd261 in BKE_object_handle_data_update /blender/source/blender/blenkernel/intern/object_update.cc:169
    #5 0x12cf64a in BKE_object_eval_uber_data /blender/source/blender/blenkernel/intern/object_update.cc:341
    #6 0x50bfba1 in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1641
    #7 0x50f1926 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61
    #8 0x50e9f6c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111
    #9 0x50e1bbf in _M_invoke /usr/include/c++/12/bits/std_function.h:290
    #10 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591
    #11 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102
    #12 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119
    #13 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166
    #14 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059
    #15 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44)

previously allocated by thread T61 here:
    #0 0x7f89706ba097 in calloc (/lib64/libasan.so.8+0xba097)
    #1 0x42785d8 in MEM_lockfree_callocN /blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:210
    #2 0xb8a2de in BoundBox* MEM_cnew<BoundBox>(char const*) /blender/intern/guardedalloc/MEM_guardedalloc.h:305
    #3 0x1272d50 in BKE_object_boundbox_calc_from_mesh /blender/source/blender/blenkernel/intern/object.cc:3796
    #4 0x306b5fe in mesh_build_data /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1419
    #5 0x306d27f in makeDerivedMesh /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1569
    #6 0x12cd261 in BKE_object_handle_data_update /blender/source/blender/blenkernel/intern/object_update.cc:169
    #7 0x12cf64a in BKE_object_eval_uber_data /blender/source/blender/blenkernel/intern/object_update.cc:341
    #8 0x50bfba1 in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1641
    #9 0x50f1926 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61
    #10 0x50e9f6c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111
    #11 0x50e1bbf in _M_invoke /usr/include/c++/12/bits/std_function.h:290
    #12 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591
    #13 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102
    #14 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119
    #15 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166
    #16 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059
    #17 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44)

Thread T69 created by T54 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)

Thread T54 created by T52 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)
    #2 0x60c0000a4ebf  (<unknown module>)

Thread T52 created by T0 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)
    #2 0x62d0000e437f  (<unknown module>)

Thread T61 created by T53 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)
    #2 0x62d0000e3f7f  (<unknown module>)

Thread T53 created by T51 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)
    #2 0x60c000098f7f  (<unknown module>)

Thread T51 created by T0 here:
    #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488)
    #2 0x60c0000090ff  (<unknown module>)

SUMMARY: AddressSanitizer: heap-use-after-free /blender/source/blender/blenkernel/intern/object.cc:3853 in BKE_object_dimensions_get
Shadow bytes around the buggy address:
  0x0c1680039ae0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa
  0x0c1680039af0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1680039b00: fa fa fa fa fa fa fa fa fa fa fa fa fd fd fd fd
  0x0c1680039b10: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
  0x0c1680039b20: fa fa fd fd fd fd fd fd fd fd fd fd fd fd fd fa
=>0x0c1680039b30: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd[fd]
  0x0c1680039b40: fd fd fd fd fd fd fa fa fa fa fa fa fa fa fd fd
  0x0c1680039b50: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c1680039b60: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c1680039b70: fd fa fa fa fa fa fa fa fa fa fd fd fd fd fd fd
  0x0c1680039b80: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
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
==199382==ABORTING
Additional ASAN info: ``` ==199382==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b00020d9f8 at pc 0x000001273d1c bp 0x7f891f442b80 sp 0x7f891f442b78 READ of size 4 at 0x60b00020d9f8 thread T69 #0 0x1273d1b in BKE_object_dimensions_get /blender/source/blender/blenkernel/intern/object.cc:3853 #1 0x69a80c2 in rna_Object_dimensions_get /blender/source/blender/makesrna/intern/rna_object.cc:1227 #2 0x69b84de in Object_dimensions_get /build_linux_debug/source/blender/makesrna/intern/rna_object_gen.cc:807 #3 0x631feff in RNA_property_float_get_array(PointerRNA*, PropertyRNA*, float*) /blender/source/blender/makesrna/intern/rna_access.cc:3063 #4 0x6320c19 in RNA_property_float_get_index(PointerRNA*, PropertyRNA*, int) /blender/source/blender/makesrna/intern/rna_access.cc:3121 #5 0x356afd7 in dtar_get_prop_val /blender/source/blender/blenkernel/intern/fcurve_driver.cc:226 #6 0x356c977 in dvar_eval_singleProp /blender/source/blender/blenkernel/intern/fcurve_driver.cc:359 #7 0x357464c in driver_get_variable_value /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1244 #8 0x357498a in evaluate_driver_sum /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1262 #9 0x3575491 in evaluate_driver /blender/source/blender/blenkernel/intern/fcurve_driver.cc:1363 #10 0x35651eb in evaluate_fcurve_driver /blender/source/blender/blenkernel/intern/fcurve.cc:2358 #11 0x3565774 in calculate_fcurve /blender/source/blender/blenkernel/intern/fcurve.cc:2412 #12 0x30e9da2 in BKE_animsys_eval_driver /blender/source/blender/blenkernel/intern/anim_sys.cc:4187 #13 0x50b5b2b in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1270 #14 0x50f0856 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_driver(ID*, FCurve*, int)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61 #15 0x50e813c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_driver(ID*, FCurve*, int)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111 #16 0x50e093f in _M_invoke /usr/include/c++/12/bits/std_function.h:290 #17 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591 #18 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102 #19 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119 #20 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166 #21 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059 #22 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44) #23 0x7f8970e42e77 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) (/build_linux_debug/bin/lib/libtbb.so.2+0x29e77) #24 0x7f8970e2b756 in tbb::internal::arena::process(tbb::internal::generic_scheduler&) (/build_linux_debug/bin/lib/libtbb.so.2+0x12756) #25 0x7f8970e39abf in tbb::internal::market::process(rml::job&) (/build_linux_debug/bin/lib/libtbb.so.2+0x20abf) #26 0x7f8970e3d59b in tbb::internal::rml::private_worker::run() (/build_linux_debug/bin/lib/libtbb.so.2+0x2459b) #27 0x7f8970e3d7d8 in tbb::internal::rml::private_worker::thread_routine(void*) (/build_linux_debug/bin/lib/libtbb.so.2+0x247d8) #28 0x7f8966cae12c in start_thread (/lib64/libc.so.6+0x8b12c) #29 0x7f8966d2fbbf in __clone3 (/lib64/libc.so.6+0x10cbbf) 0x60b00020d9f8 is located 56 bytes inside of 112-byte region [0x60b00020d9c0,0x60b00020da30) freed by thread T0 here: #0 0x7f89706b9388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388) #1 0x4277ea3 in MEM_lockfree_freeN /blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:104 #2 0x1258e5f in BKE_object_free_derived_caches /blender/source/blender/blenkernel/intern/object.cc:1794 #3 0x306cf56 in makeDerivedMesh /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1550 #4 0x12cd261 in BKE_object_handle_data_update /blender/source/blender/blenkernel/intern/object_update.cc:169 #5 0x12cf64a in BKE_object_eval_uber_data /blender/source/blender/blenkernel/intern/object_update.cc:341 #6 0x50bfba1 in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1641 #7 0x50f1926 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61 #8 0x50e9f6c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111 #9 0x50e1bbf in _M_invoke /usr/include/c++/12/bits/std_function.h:290 #10 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591 #11 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102 #12 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119 #13 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166 #14 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059 #15 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44) previously allocated by thread T61 here: #0 0x7f89706ba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x42785d8 in MEM_lockfree_callocN /blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:210 #2 0xb8a2de in BoundBox* MEM_cnew<BoundBox>(char const*) /blender/intern/guardedalloc/MEM_guardedalloc.h:305 #3 0x1272d50 in BKE_object_boundbox_calc_from_mesh /blender/source/blender/blenkernel/intern/object.cc:3796 #4 0x306b5fe in mesh_build_data /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1419 #5 0x306d27f in makeDerivedMesh /blender/source/blender/blenkernel/intern/DerivedMesh.cc:1569 #6 0x12cd261 in BKE_object_handle_data_update /blender/source/blender/blenkernel/intern/object_update.cc:169 #7 0x12cf64a in BKE_object_eval_uber_data /blender/source/blender/blenkernel/intern/object_update.cc:341 #8 0x50bfba1 in operator() /blender/source/blender/depsgraph/intern/builder/deg_builder_nodes.cc:1641 #9 0x50f1926 in __invoke_impl<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:61 #10 0x50e9f6c in __invoke_r<void, blender::deg::DepsgraphNodeBuilder::build_object_data_geometry(Object*)::<lambda(Depsgraph*)>&, Depsgraph*> /usr/include/c++/12/bits/invoke.h:111 #11 0x50e1bbf in _M_invoke /usr/include/c++/12/bits/std_function.h:290 #12 0x500b280 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const /usr/include/c++/12/bits/std_function.h:591 #13 0x5005861 in evaluate_node /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:102 #14 0x5005c93 in deg_task_run_func /blender/source/blender/depsgraph/intern/eval/deg_eval.cc:119 #15 0x421ec72 in Task::operator()() const /blender/source/blender/blenlib/intern/task_pool.cc:166 #16 0x4223aaa in tbb::internal::function_task<Task>::execute() /lib/linux_x86_64_glibc_228/tbb/include/tbb/task.h:1059 #17 0x7f8970e42b44 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (/build_linux_debug/bin/lib/libtbb.so.2+0x29b44) Thread T69 created by T54 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) Thread T54 created by T52 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) #2 0x60c0000a4ebf (<unknown module>) Thread T52 created by T0 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) #2 0x62d0000e437f (<unknown module>) Thread T61 created by T53 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) #2 0x62d0000e3f7f (<unknown module>) Thread T53 created by T51 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) #2 0x60c000098f7f (<unknown module>) Thread T51 created by T0 here: #0 0x7f897064b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6) #1 0x7f8970e3d488 in tbb::internal::rml::private_server::wake_some(int) (/build_linux_debug/bin/lib/libtbb.so.2+0x24488) #2 0x60c0000090ff (<unknown module>) SUMMARY: AddressSanitizer: heap-use-after-free /blender/source/blender/blenkernel/intern/object.cc:3853 in BKE_object_dimensions_get Shadow bytes around the buggy address: 0x0c1680039ae0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa 0x0c1680039af0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1680039b00: fa fa fa fa fa fa fa fa fa fa fa fa fd fd fd fd 0x0c1680039b10: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa 0x0c1680039b20: fa fa fd fd fd fd fd fd fd fd fd fd fd fd fd fa =>0x0c1680039b30: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd[fd] 0x0c1680039b40: fd fd fd fd fd fd fa fa fa fa fa fa fa fa fd fd 0x0c1680039b50: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0c1680039b60: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c1680039b70: fd fa fa fa fa fa fa fa fa fa fd fd fd fd fd fd 0x0c1680039b80: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa 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 ==199382==ABORTING ```
Member

@Sergey : seems something is not threadsafe, I think I cant repro with blender -t 1

@Sergey : seems something is not threadsafe, I _think_ I cant repro with `blender -t 1`

@lichtwerk Dependency cycle solver will remove a random relation to solve the cycle. And relations is what ensures thread safety, by making it so depsgraph operations are only executed when inputs are ready.

There are some special tricks in the graph to make it so if the execution order wasn't correct an access to outdated but valid data happens instead of a crash.

P.S. On a related note, it is not really guaranteed that -t 1 will solve crashes when there are dependency cycles. It might, or might solve them. It is still possible that operation nodes are executed one at a time, but in a wrong order, causing crash.

@lichtwerk Dependency cycle solver will remove a random relation to solve the cycle. And relations is what ensures thread safety, by making it so depsgraph operations are only executed when inputs are ready. There are some special tricks in the graph to make it so if the execution order wasn't correct an access to outdated but valid data happens instead of a crash. P.S. On a related note, it is not really guaranteed that `-t 1` will solve crashes when there are dependency cycles. It might, or might solve them. It is still possible that operation nodes are executed one at a time, but in a wrong order, causing crash.

Potentially caused by c67e5628d2
@HooglyBoogly /^

Potentially caused by https://projects.blender.org/blender/blender/commit/c67e5628d22f8348492b6205081fe1798d50689c @HooglyBoogly /^
Iliya Katushenock added this to the 3.6 LTS milestone 2023-08-15 13:34:10 +02:00
Member

Not sure it's related to that commit. But #96968 is related. Though retrieving a mesh bounding box is threadsafe, functions like BKE_object_dimensions_get are not. I'd like to go further in the refactors for bounds to make it so objects don't have their own bounds cache but just return the cached bounds of their geometry. I don't fully understand the specific problem reported here, but I think that would fix it.

Not sure it's related to that commit. But #96968 is related. Though retrieving a mesh bounding box is threadsafe, functions like `BKE_object_dimensions_get` are not. I'd like to go further in the refactors for bounds to make it so objects don't have their own bounds cache but just return the cached bounds of their geometry. I don't _fully_ understand the specific problem reported here, but I think that would fix it.

Any updates here please?

Any updates here please?

The problem here is that dependency cycle prevents a typical flow when all operations are executed when their inputs are ready. This leads to situation that a driver access an object's "dimensions" and those do on-demand calculation of bounds and that calculation accesses object's evaluated state which is freed in a parallel thread as part of modifier stack evaluation.

We do evaluate the bounding box as part of modifier stack already. It might make it easier to avoid non-thread safe access.
But as Hans identified already, making BKE_object_dimensions_get thread-safe (not only from multiple threads accessing data point of view, but also from the function itself accessing possibly stale data) is the solution to this crash.

Not sure how far Hans for into the refactors.

The problem here is that dependency cycle prevents a typical flow when all operations are executed when their inputs are ready. This leads to situation that a driver access an object's "`dimensions`" and those do on-demand calculation of bounds and that calculation accesses object's evaluated state which is freed in a parallel thread as part of modifier stack evaluation. We do evaluate the bounding box as part of modifier stack already. It might make it easier to avoid non-thread safe access. But as Hans identified already, making `BKE_object_dimensions_get` thread-safe (not only from multiple threads accessing data point of view, but also from the function itself accessing possibly stale data) is the solution to this crash. Not sure how far Hans for into the refactors.
Hans Goudey added
Type
Bug
and removed
Type
Report
labels 2023-10-09 22:08:28 +02:00
Hans Goudey self-assigned this 2023-10-10 00:20:38 +02:00
Member

I finished the bounds fix in #113465, but I realized that's not enough to fix the bug after testing it.
It looks like the evaluated mesh is still totally freed: vert_data->totlayer is -1 and the rest of the struct is cleared.
I'm worried that means a deeper change is necessary here, and I'm not sure how this ever worked before.

I finished the bounds fix in #113465, but I realized that's not enough to fix the bug after testing it. It looks like the evaluated mesh is still totally freed: `vert_data->totlayer` is `-1` and the rest of the struct is cleared. I'm worried that means a deeper change is necessary here, and I'm not sure how this ever worked before.

Just to move some information we've exchanged in the chat to a more permanent place.

What happens is that the BKE_mesh_boundbox_get accesses ob->data, and after that another thread frees derived meshes for that object, which makes its previous ob->data invalid.

I am not sure it ever really worked before because even the old code was accessing ob->data, so might have some timings changed with different threading primitives used. I only tested current state of the main branch, and did not go into much older revisions.

I am not currently sure what would be the best solution of the threading conflict, but some ideas:

  • Make Object_Runtime::bb a value, always eagerly initialize it in the modifier evaluation
  • Guard access of the object->data in the BKE_object_dimensions_get , BKE_object_free_derived_caches, BKE_object_eval_assign_data with the same mutex lock. So worst case BKE_object_dimensions_get accesses the "input" mesh, and not the evaluated one (which is what one would expect when there is dependency cycle which prevents proper evaluation order).
Just to move some information we've exchanged in the chat to a more permanent place. What happens is that the `BKE_mesh_boundbox_get` accesses `ob->data`, and after that another thread frees derived meshes for that object, which makes its previous `ob->data` invalid. I am not sure it ever really worked before because even the old code was accessing `ob->data`, so might have some timings changed with different threading primitives used. I only tested current state of the main branch, and did not go into much older revisions. I am not currently sure what would be the best solution of the threading conflict, but some ideas: - Make `Object_Runtime::bb` a value, always eagerly initialize it in the modifier evaluation - Guard access of the `object->data` in the `BKE_object_dimensions_get `, `BKE_object_free_derived_caches`, `BKE_object_eval_assign_data` with the same mutex lock. So worst case `BKE_object_dimensions_get` accesses the "input" mesh, and not the evaluated one (which is what one would expect when there is dependency cycle which prevents proper evaluation order).

Finally managed to get Blender 3.3 with ASAN compiled locally.

So as the intuitive suspecion suggested, this is not really a regression as the crash can be reproduced there as well:

=================================================================
==64749==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001647370e8 at pc 0x0001015f8264 bp 0x0002b28ebdb0 sp 0x0002b28ebda8
READ of size 4 at 0x0001647370e8 thread T30
    #0 0x1015f8260 in blender::vec_base<float, 3>::vec_base(float const*) BLI_math_vec_types.hh:196
    #1 0x1015f7f30 in blender::vec_base<float, 3>::vec_base(float const*) BLI_math_vec_types.hh:194
    #2 0x10298eed8 in BKE_mesh_minmax::$_0::operator()(blender::IndexRange, BKE_mesh_minmax::Result const&) const mesh.cc:1580
    #3 0x10298e56c in BKE_mesh_minmax::Result blender::threading::parallel_reduce<BKE_mesh_minmax::Result, BKE_mesh_minmax::$_0, BKE_mesh_minmax::$_1>(blender::IndexRange, long long, BKE_mesh_minmax::Result const&, BKE_mesh_minmax::$_0 const&, BKE_mesh_minmax::$_1 const&) BLI_task.hh:92
    #4 0x10298dda4 in BKE_mesh_minmax mesh.cc:1573
    #5 0x102c4267c in BKE_mesh_wrapper_minmax mesh_wrapper.cc:161
    #6 0x10297de40 in BKE_mesh_boundbox_get mesh.cc:1216
    #7 0x102f243dc in BKE_object_boundbox_get object.cc:3690
    #8 0x102eecf50 in BKE_object_dimensions_get object.cc:3788
    #9 0x1088b625c in rna_Object_dimensions_get rna_object.c:1234
    #10 0x1088b6188 in Object_dimensions_get rna_object_gen.c:800
    #11 0x107ef7ffc in RNA_property_float_get_array rna_access.c:2907
    #12 0x107ef9e3c in RNA_property_float_get_index rna_access.c:2965
    #13 0x101d367ec in dtar_get_prop_val fcurve_driver.c:149
    #14 0x101d3002c in dvar_eval_singleProp fcurve_driver.c:282
    #15 0x101d3c648 in driver_get_variable_value fcurve_driver.c:1139
    #16 0x101d3ce94 in evaluate_driver_sum fcurve_driver.c:1156
    #17 0x101d3caa8 in evaluate_driver fcurve_driver.c:1253
    #18 0x101d22748 in evaluate_fcurve_driver fcurve.c:2164
    #19 0x101d23014 in calculate_fcurve fcurve.c:2218
    #20 0x100f94978 in BKE_animsys_eval_driver anim_sys.c:4211

While it is still an important issue to be solved, it is not technically high-priority. So we can look into proper solutions, without worry of keeping them as safe as possible for 4.0 release.

Finally managed to get Blender 3.3 with ASAN compiled locally. So as the intuitive suspecion suggested, this is not really a regression as the crash can be reproduced there as well: ``` ================================================================= ==64749==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001647370e8 at pc 0x0001015f8264 bp 0x0002b28ebdb0 sp 0x0002b28ebda8 READ of size 4 at 0x0001647370e8 thread T30 #0 0x1015f8260 in blender::vec_base<float, 3>::vec_base(float const*) BLI_math_vec_types.hh:196 #1 0x1015f7f30 in blender::vec_base<float, 3>::vec_base(float const*) BLI_math_vec_types.hh:194 #2 0x10298eed8 in BKE_mesh_minmax::$_0::operator()(blender::IndexRange, BKE_mesh_minmax::Result const&) const mesh.cc:1580 #3 0x10298e56c in BKE_mesh_minmax::Result blender::threading::parallel_reduce<BKE_mesh_minmax::Result, BKE_mesh_minmax::$_0, BKE_mesh_minmax::$_1>(blender::IndexRange, long long, BKE_mesh_minmax::Result const&, BKE_mesh_minmax::$_0 const&, BKE_mesh_minmax::$_1 const&) BLI_task.hh:92 #4 0x10298dda4 in BKE_mesh_minmax mesh.cc:1573 #5 0x102c4267c in BKE_mesh_wrapper_minmax mesh_wrapper.cc:161 #6 0x10297de40 in BKE_mesh_boundbox_get mesh.cc:1216 #7 0x102f243dc in BKE_object_boundbox_get object.cc:3690 #8 0x102eecf50 in BKE_object_dimensions_get object.cc:3788 #9 0x1088b625c in rna_Object_dimensions_get rna_object.c:1234 #10 0x1088b6188 in Object_dimensions_get rna_object_gen.c:800 #11 0x107ef7ffc in RNA_property_float_get_array rna_access.c:2907 #12 0x107ef9e3c in RNA_property_float_get_index rna_access.c:2965 #13 0x101d367ec in dtar_get_prop_val fcurve_driver.c:149 #14 0x101d3002c in dvar_eval_singleProp fcurve_driver.c:282 #15 0x101d3c648 in driver_get_variable_value fcurve_driver.c:1139 #16 0x101d3ce94 in evaluate_driver_sum fcurve_driver.c:1156 #17 0x101d3caa8 in evaluate_driver fcurve_driver.c:1253 #18 0x101d22748 in evaluate_fcurve_driver fcurve.c:2164 #19 0x101d23014 in calculate_fcurve fcurve.c:2218 #20 0x100f94978 in BKE_animsys_eval_driver anim_sys.c:4211 ``` While it is still an important issue to be solved, it is not technically high-priority. So we can look into proper solutions, without worry of keeping them as safe as possible for 4.0 release.
Sergey Sharybin added
Priority
Normal
and removed
Priority
High
labels 2023-10-10 16:17:35 +02:00
Hans Goudey removed their assignment 2023-10-13 10:21:41 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info 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
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#111120
No description provided.