Background scene cause a crash in render animation #83852

New Issue

Yashar · 2020-12-16T15:58:49+01:00

Yashar commented

2020-12-16 15:58:49 +01:00

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.55

Blender Version
Broken: version:

2.92.0 Alpha, branch: master, commit date: 2020-12-15 23:20, hash: 977bd7937a
2.91.0
2.90.1
Worked: 2.83.9

Short description of error
Background scene makes blender unstable and cause a crash in render animation

Exact steps for others to reproduce the error

Open default startup file.
Create a new scene named "Scene.001".
Assign default scene "Scene" as the background scene of "Scene.001" in scene properties.
Assign default camera as the camera of "Scene.001" in scene properties.
Hit render animation from render menu.
After a couple of frames rendered, blender crashes.

Tested in different situations i had some problems.
I think assigning a background scene makes blender unstable in general.
Occasionally crashes when opening a file which has background scene.
The worst case is render animation.

Background_Scene_Crash.mp4

Reproduction steps with this file:

Open file.
Start Render Animation.
#83852.blend

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.55 **Blender Version** Broken: version: - 2.92.0 Alpha, branch: master, commit date: 2020-12-15 23:20, hash: `977bd7937a` - 2.91.0 - 2.90.1 Worked: 2.83.9 **Short description of error** Background scene makes blender unstable and cause a crash in render animation **Exact steps for others to reproduce the error** - Open default startup file. - Create a new scene named "Scene.001". - Assign default scene "Scene" as the background scene of "Scene.001" in scene properties. - Assign default camera as the camera of "Scene.001" in scene properties. - Hit render animation from render menu. - After a couple of frames rendered, blender crashes. Tested in different situations i had some problems. I think assigning a background scene makes blender unstable in general. Occasionally crashes when opening a file which has background scene. The worst case is render animation. [Background_Scene_Crash.mp4](https://archive.blender.org/developer/F9513354/Background_Scene_Crash.mp4) Reproduction steps with this file: 1. Open file. 2. Start Render Animation. [#83852.blend](https://archive.blender.org/developer/F9553098/T83852.blend)

Yashar commented

2020-12-16 15:58:49 +01:00

Added subscriber: @Yashar

Robert Guetzkow commented

2020-12-17 12:15:17 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-12-17 12:15:17 +01:00

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

Robert Guetzkow commented

2020-12-17 12:15:17 +01:00

I can reproduce the problem. I'm tagging this as Nodes & Physics as this seems to be a dependency graph issue by the looks of it.

libc.so.6!__GI_raise(int sig) (/build/glibc-ZN95T4/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:50)
libc.so.6!__GI_abort() (/build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:79)
_BLI_assert_abort() (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/BLI_assert.c:50)
BKE_object_eval_eval_base_flags(Depsgraph * depsgraph, Scene * scene, const int view_layer_index, Object * object, int base_index, const _Bool is_from_set) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenkernel/intern/object_update.c:454)
std::__invoke_impl<void, void (*&)(Depsgraph*, Scene*, int, Object*, int, bool), Depsgraph*, Scene*&, int&, Object*&, int&, bool&>(void (*&)(Depsgraph *, Scene *, int, Object *, int, bool) __f) (/usr/include/c++/9/bits/invoke.h:60)
std::__invoke<void (*&)(Depsgraph*, Scene*, int, Object*, int, bool), Depsgraph*, Scene*&, int&, Object*&, int&, bool&>(void (*&)(Depsgraph *, Scene *, int, Object *, int, bool) __fn) (/usr/include/c++/9/bits/invoke.h:95)
std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)>::__call<void, Depsgraph*&&, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul>(std::tuple<Depsgraph*&&>&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul, 5ul>)(std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> * const this, std::tuple<Depsgraph*&&> && __args) (/usr/include/c++/9/functional:400)
std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)>::operator()<Depsgraph*, void>(Depsgraph*&&)(std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> * const this) (/usr/include/c++/9/functional:484)
std::_Function_handler<void (Depsgraph*), std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> >::_M_invoke(std::_Any_data const&, Depsgraph*&&)(const std::_Any_data & __functor,  __args#0) (/usr/include/c++/9/bits/std_function.h:300)
std::function<void (Depsgraph*)>::operator()(Depsgraph*) const(const std::function<void(Depsgraph*)> * const this,  __args#0) (/usr/include/c++/9/bits/std_function.h:688)
blender::deg::(anonymous namespace)::evaluate_node(const blender::deg::(anonymous namespace)::DepsgraphEvalState * state, blender::deg::OperationNode * operation_node) (/home/dev/01-data/01-git/blender-git/blender/source/blender/depsgraph/intern/eval/deg_eval.cc:113)
blender::deg::(anonymous namespace)::deg_task_run_func(TaskPool * pool, void * taskdata) (/home/dev/01-data/01-git/blender-git/blender/source/blender/depsgraph/intern/eval/deg_eval.cc:124)
Task::operator()() const::{lambda()#1}::operator()() const(const Task::<lambda()> * const __closure) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/task_pool.cc:118)
tbb::interface7::internal::delegated_function<Task::operator()() const::{lambda()#1} const, void>::operator()() const(const tbb::interface7::internal::delegated_function<const Task::operator()() const::<lambda()>, void> * const this) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:93)
tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long) (Unknown Source:0)
tbb::interface7::internal::isolate_impl<void, Task::operator()() const::{lambda()#1} const>(Task::operator()() const::{lambda()#1} const&)(const Task::<lambda()> & f) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:160)
tbb::interface7::this_task_arena::isolate<Task::operator()() const::{lambda()#1}>(tbb::interface7::internal::return_type_or_void const&)(const Task::<lambda()> & f) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:395)
Task::operator()(const Task * const this) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/task_pool.cc:118)
tbb::internal::function_task<Task>::execute(tbb::internal::function_task<Task> * const this) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task.h:1048)
tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (Unknown Source:0)

I can reproduce the problem. I'm tagging this as *Nodes & Physics* as this seems to be a dependency graph issue by the looks of it. ```lines libc.so.6!__GI_raise(int sig) (/build/glibc-ZN95T4/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:50) libc.so.6!__GI_abort() (/build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:79) _BLI_assert_abort() (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/BLI_assert.c:50) BKE_object_eval_eval_base_flags(Depsgraph * depsgraph, Scene * scene, const int view_layer_index, Object * object, int base_index, const _Bool is_from_set) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenkernel/intern/object_update.c:454) std::__invoke_impl<void, void (*&)(Depsgraph*, Scene*, int, Object*, int, bool), Depsgraph*, Scene*&, int&, Object*&, int&, bool&>(void (*&)(Depsgraph *, Scene *, int, Object *, int, bool) __f) (/usr/include/c++/9/bits/invoke.h:60) std::__invoke<void (*&)(Depsgraph*, Scene*, int, Object*, int, bool), Depsgraph*, Scene*&, int&, Object*&, int&, bool&>(void (*&)(Depsgraph *, Scene *, int, Object *, int, bool) __fn) (/usr/include/c++/9/bits/invoke.h:95) std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)>::__call<void, Depsgraph*&&, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul>(std::tuple<Depsgraph*&&>&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul, 5ul>)(std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> * const this, std::tuple<Depsgraph*&&> && __args) (/usr/include/c++/9/functional:400) std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)>::operator()<Depsgraph*, void>(Depsgraph*&&)(std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> * const this) (/usr/include/c++/9/functional:484) std::_Function_handler<void (Depsgraph*), std::_Bind<void (*(std::_Placeholder<1>, Scene*, int, Object*, int, bool))(Depsgraph*, Scene*, int, Object*, int, bool)> >::_M_invoke(std::_Any_data const&, Depsgraph*&&)(const std::_Any_data & __functor, __args#0) (/usr/include/c++/9/bits/std_function.h:300) std::function<void (Depsgraph*)>::operator()(Depsgraph*) const(const std::function<void(Depsgraph*)> * const this, __args#0) (/usr/include/c++/9/bits/std_function.h:688) blender::deg::(anonymous namespace)::evaluate_node(const blender::deg::(anonymous namespace)::DepsgraphEvalState * state, blender::deg::OperationNode * operation_node) (/home/dev/01-data/01-git/blender-git/blender/source/blender/depsgraph/intern/eval/deg_eval.cc:113) blender::deg::(anonymous namespace)::deg_task_run_func(TaskPool * pool, void * taskdata) (/home/dev/01-data/01-git/blender-git/blender/source/blender/depsgraph/intern/eval/deg_eval.cc:124) Task::operator()() const::{lambda()#1}::operator()() const(const Task::<lambda()> * const __closure) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/task_pool.cc:118) tbb::interface7::internal::delegated_function<Task::operator()() const::{lambda()#1} const, void>::operator()() const(const tbb::interface7::internal::delegated_function<const Task::operator()() const::<lambda()>, void> * const this) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:93) tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long) (Unknown Source:0) tbb::interface7::internal::isolate_impl<void, Task::operator()() const::{lambda()#1} const>(Task::operator()() const::{lambda()#1} const&)(const Task::<lambda()> & f) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:160) tbb::interface7::this_task_arena::isolate<Task::operator()() const::{lambda()#1}>(tbb::interface7::internal::return_type_or_void const&)(const Task::<lambda()> & f) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task_arena.h:395) Task::operator()(const Task * const this) (/home/dev/01-data/01-git/blender-git/blender/source/blender/blenlib/intern/task_pool.cc:118) tbb::internal::function_task<Task>::execute(tbb::internal::function_task<Task> * const this) (/home/dev/01-data/01-git/blender-git/lib/linux_centos7_x86_64/tbb/include/tbb/task.h:1048) tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) (Unknown Source:0) ```

Jacques Lucke commented

2021-01-06 13:35:28 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-01-06 13:35:28 +01:00

My stack trace is essentially the same.
This assert fails in BKE_object_eval_eval_base_flags: BLI_assert(view_layer->object_bases_array != NULL);.

My stack trace is essentially the same. This assert fails in `BKE_object_eval_eval_base_flags`: `BLI_assert(view_layer->object_bases_array != NULL);`.

sentharn commented

2022-01-24 04:05:49 +01:00

Added subscriber: @sentharn

sentharn commented

2022-01-24 04:05:49 +01:00

I can confirm this bug is still happening in blender-3.1.0-alpha+daily.5fca280c803b and blender 3.0.

My colleague's scene, in blender 3.0, is also crashing after almost every frame of his animation, or rather at the start of the next frame, at the same exception address that I just crashed on: 0x00007FF63559F88Ein BKE_object_eval_eval_base_flags

I am trying to find out if he's using background scenes as well.

Here's my Blender 3.0 stack trace; this one actually crashed on startup for me.

#83852.crash.txt

And here's a blender-3.1.0-alpha+daily.5fca280c803b backtrace (same function name, different address of course). Also crashed on startup.

#83852.crash.txt

On both 3.0 and 3.1 I did manage to get it to start and then crash on render at least once, but I don't have the crash traces handy as the file now tends to crash on startup instead.

Can someone please edit the ticket to reflect that it is still crashing in 3.0 and 3.1 alpha?

I can confirm this bug is still happening in **blender-3.1.0-alpha+daily.5fca280c803b** and blender 3.0. My colleague's scene, in blender 3.0, is also crashing after almost every frame of his animation, or rather at the start of the next frame, at the same exception address that I just crashed on: **0x00007FF63559F88E**in BKE_object_eval_eval_base_flags I am trying to find out if he's using background scenes as well. Here's my **Blender 3.0** stack trace; this one actually crashed on startup for me. [#83852.crash.txt](https://archive.blender.org/developer/F12820285/T83852.crash.txt) And here's a **blender-3.1.0-alpha+daily.5fca280c803b** backtrace (same function name, different address of course). Also crashed on startup. [#83852.crash.txt](https://archive.blender.org/developer/F12820290/T83852.crash.txt) On both 3.0 and 3.1 I did manage to get it to start and then crash on render at least once, but I don't have the crash traces handy as the file now tends to crash on startup instead. Can someone please edit the ticket to reflect that it is still crashing in 3.0 and 3.1 alpha?

Hans Goudey commented

2022-01-24 04:20:36 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-01-24 04:20:36 +01:00

I'll raise the priority since this is a confirmed crash (though I couldn't seem to reproduce this myself).
Also, according the the module page, the dependency graph is a #Core module topic, rather than #nodes_physics (which makes more sense to me anyway).

I'll raise the priority since this is a confirmed crash (though I couldn't seem to reproduce this myself). Also, according the the module page, the dependency graph is a #Core module topic, rather than #nodes_physics (which makes more sense to me anyway).

sentharn commented

2022-01-24 04:50:52 +01:00

FYI for people trying to repro: it may take a few tries. Sometimes changing render engine and trying again helps; sometimes it'll crash on first render; usually it crashes on file load for me. I'm on Windows 10; I'll try on a Linux box when I get access later this week.

Bastien Montagne commented

2022-01-24 16:18:42 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2022-01-24 16:18:42 +01:00

Not sure why high priority, not all crashes are 'high'... This one has been reported since 2.90, and seems to be hard to reproduce, so this is likely a fairly niche issue.

sentharn commented

2022-01-24 19:20:53 +01:00

In #83852#1293997, @mont29 wrote:
Not sure why high priority, not all crashes are 'high'... This one has been reported since 2.90, and seems to be hard to reproduce, so this is likely a fairly niche issue.

Agreed about "high" but, it is not that hard to reproduce--it just takes multiple tries because it is inconsistent. I reproduced this in about 1 minute using the original submitter's attached file, on an Ubuntu 20.04 machine running 3.0 with a brand new configuration. So now it is reproducible on two platforms, Windows 10 and Linux, on Blender 3.0.

My exact steps to reproduce were to open the file -> go to a new project -> open the file -> go to a new project -> open the file again, then crash on open.

Sometimes it will crash immediately, sometimes it takes a few tries. (Race condition maybe? Ugh.) So don't expect it to magically happen only on the 3rd try.

Here's the crash.txt from the Linux machine. Same function+offset as on Windows 10: BKE_object_eval_eval_base_flags+0x3d

#83852.crash.txt

I mentioned that a colleague is having the same issue. I just heard back from him that he's not using the Background Scene feature, but he's crashing at the same location between frames. I'm not sure if this is something that should be tied to this bug report or not. Same crash location but potentially a different cause--a wider issue with multiple triggers?

Just in case, here's the info from his crash:

# backtrace
Exception Record:

ExceptionCode         : EXCEPTION_ACCESS_VIOLATION
Exception Address     : 0x00007FF73390F88E
Exception Module      : blender.exe
Exception Flags       : 0x00000000
Exception Parameters  : 0x2
Parameters[0] : 0x0000000000000000
Parameters[1] : 0x0000000000000098

Please let me know what you recommend to help.

> In #83852#1293997, @mont29 wrote: > Not sure why high priority, not all crashes are 'high'... This one has been reported since 2.90, and seems to be hard to reproduce, so this is likely a fairly niche issue. Agreed about "high" but, it is not that hard to reproduce--it just takes multiple tries because it is inconsistent. I reproduced this in about 1 minute using the original submitter's attached file, on an Ubuntu 20.04 machine running 3.0 with a brand new configuration. So now it is reproducible on two platforms, Windows 10 and Linux, on Blender 3.0. My exact steps to reproduce were to open the file -> go to a new project -> open the file -> go to a new project -> open the file again, then crash on open. Sometimes it will crash immediately, sometimes it takes a few tries. (Race condition maybe? Ugh.) So don't expect it to magically happen only on the 3rd try. Here's the crash.txt from the Linux machine. Same function+offset as on Windows 10: **BKE_object_eval_eval_base_flags+0x3d** [#83852.crash.txt](https://archive.blender.org/developer/F12821580/T83852.crash.txt) I mentioned that a colleague is having the same issue. I just heard back from him that he's not using the Background Scene feature, but he's crashing at the same location between frames. I'm not sure if this is something that should be tied to this bug report or not. Same crash location but potentially a different cause--a wider issue with multiple triggers? Just in case, here's the info from his crash: ``` # backtrace Exception Record: ExceptionCode : EXCEPTION_ACCESS_VIOLATION Exception Address : 0x00007FF73390F88E Exception Module : blender.exe Exception Flags : 0x00000000 Exception Parameters : 0x2 Parameters[0] : 0x0000000000000000 Parameters[1] : 0x0000000000000098 ``` ![st.png](https://archive.blender.org/developer/F12821584/st.png) Please let me know what you recommend to help.

sentharn commented

2022-01-24 20:00:52 +01:00

It took much longer with a debug build of v3.0.0 (you can see how many times I had to load the file) but here's the log along with the failing assert that is probably a symptom of the issue:

*BLI_assert failed: source/blender/blenkernel/intern/object_update.c:469, BKE_object_eval_eval_base_flags(), at 'view_layer->object_bases_array != ((void )0)'

Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Saved: '/tmp/0001.png'
 Time: 00:01.35 (Saving: 00:01.04)

Saved: '/tmp/0002.png'
 Time: 00:00.47 (Saving: 00:00.29)

Saved: '/tmp/0003.png'
 Time: 00:00.46 (Saving: 00:00.28)

Saved: '/tmp/0004.png'
 Time: 00:00.49 (Saving: 00:00.31)

Saved: '/tmp/0005.png'
 Time: 00:00.48 (Saving: 00:00.29)

Saved: '/tmp/0006.png'
 Time: 00:00.46 (Saving: 00:00.28)

Saved: '/tmp/0007.png'
 Time: 00:00.47 (Saving: 00:00.28)

Saved: '/tmp/0008.png'
 Time: 00:00.48 (Saving: 00:00.30)

Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
Read blend: /tmp/T83852.blend
./blender(BLI_system_backtrace+0x39) [0x10746e1e]
./blender(_BLI_assert_print_backtrace+0x1a) [0x105f3950]
./blender(BKE_object_eval_eval_base_flags+0xb6) [0x3afbdc8]
./blender() [0x44343cb]
./blender() [0x443bdbc]
./blender(_ZNKSt8functionIFvP9DepsgraphEEclES1_+0x4d) [0x4415c85]
./blender() [0x4414e29]
./blender() [0x4414e73]
./blender(_ZNK4TaskclEv+0x2f) [0x1074d909]
./blender() [0x1074e6d8]
./blender() [0x40c09a5]
./blender() [0x40c0c5b]
./blender() [0x40af857]
./blender() [0x40ba690]
./blender() [0x40bc6cc]
./blender() [0x40bc8c9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f485dafd609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f485d4dd293]
BLI_assert failed: source/blender/blenkernel/intern/object_update.c:469, BKE_object_eval_eval_base_flags(), at 'view_layer->object_bases_array != ((void *)0)'
Aborted (core dumped)

It took much longer with a debug build of v3.0.0 (you can see how many times I had to load the file) but here's the log along with the failing assert that is probably a symptom of the issue: **BLI_assert failed: source/blender/blenkernel/intern/object_update.c:469, BKE_object_eval_eval_base_flags(), at 'view_layer->object_bases_array != ((void *)0)'** ``` Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Saved: '/tmp/0001.png' Time: 00:01.35 (Saving: 00:01.04) Saved: '/tmp/0002.png' Time: 00:00.47 (Saving: 00:00.29) Saved: '/tmp/0003.png' Time: 00:00.46 (Saving: 00:00.28) Saved: '/tmp/0004.png' Time: 00:00.49 (Saving: 00:00.31) Saved: '/tmp/0005.png' Time: 00:00.48 (Saving: 00:00.29) Saved: '/tmp/0006.png' Time: 00:00.46 (Saving: 00:00.28) Saved: '/tmp/0007.png' Time: 00:00.47 (Saving: 00:00.28) Saved: '/tmp/0008.png' Time: 00:00.48 (Saving: 00:00.30) Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend Read blend: /tmp/T83852.blend ./blender(BLI_system_backtrace+0x39) [0x10746e1e] ./blender(_BLI_assert_print_backtrace+0x1a) [0x105f3950] ./blender(BKE_object_eval_eval_base_flags+0xb6) [0x3afbdc8] ./blender() [0x44343cb] ./blender() [0x443bdbc] ./blender(_ZNKSt8functionIFvP9DepsgraphEEclES1_+0x4d) [0x4415c85] ./blender() [0x4414e29] ./blender() [0x4414e73] ./blender(_ZNK4TaskclEv+0x2f) [0x1074d909] ./blender() [0x1074e6d8] ./blender() [0x40c09a5] ./blender() [0x40c0c5b] ./blender() [0x40af857] ./blender() [0x40ba690] ./blender() [0x40bc6cc] ./blender() [0x40bc8c9] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f485dafd609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f485d4dd293] BLI_assert failed: source/blender/blenkernel/intern/object_update.c:469, BKE_object_eval_eval_base_flags(), at 'view_layer->object_bases_array != ((void *)0)' Aborted (core dumped) ```

sentharn commented

2022-01-26 03:45:37 +01:00

I think this problem may be deeper than the background scene feature. The colleague I mentioned got back to me and said he was using FLIP Fluids. I know, not supported here. For the record, my bug reports in this thread were reproduced withoutit.

We discovered that https://github.com/rlguy/Blender-FLIP-Fluids/issues/566 was the cause of his crash. Digging into that bug report led me to #76422 which appears to be an access violation on the same line that is giving us grief for this bug here. This is making me think that there's some sort of race condition involved with the depsgraph despite blender/blender-addons#60094 being merged in for 2.81 (which makes FLIP more stable as per the Github bug report), and I don't think FLIP Fluids is the only thing that can cause it since we're having problems in 3.0 and 3.1 now with the file attached to this bug report here on a completely different feature.

Yes, he uses Lock Interface, although in this case he was command line rendering. He successfully rendered the project by scripting blender to start for every frame of the animation to render 1 frame.

Hopefully all these little breadcrumbs can help track down the issue; I'm about at the limit of my debugging knowledge here.

I think this problem may be deeper than the background scene feature. The colleague I mentioned got back to me and said he was using FLIP Fluids. I know, not supported here. For the record, my bug reports in this thread were reproduced **without**it. We discovered that https://github.com/rlguy/Blender-FLIP-Fluids/issues/566 was the cause of his crash. Digging into that bug report led me to #76422 which appears to be an access violation on the same line that is giving us grief for this bug here. This is making me think that there's some sort of race condition involved with the depsgraph despite blender/blender-addons#60094 being merged in for 2.81 (which makes FLIP more stable as per the Github bug report), and I don't think FLIP Fluids is the only thing that can cause it since we're having problems in 3.0 and 3.1 now with the file attached to this bug report here on a completely different feature. Yes, he uses Lock Interface, although in this case he was command line rendering. He successfully rendered the project by scripting blender to start for every frame of the animation to render 1 frame. Hopefully all these little breadcrumbs can help track down the issue; I'm about at the limit of my debugging knowledge here.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Background scene cause a crash in render animation #83852