VSE: BLI_assert fails while rendering strip with changed font #75822

New Issue

Vincent Blankfield · 2020-04-17T12:11:47+02:00

2020-04-17 12:11:47 +02:00

System Information
Operating system: Windows-10-10.0.14393-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19

Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-04-17 09:30, hash: 40d90456ea
Worked: unknown

Short description of error
On Windows VSE fails the BLI_assert(BLI_thread_is_main()) assert at BKE_sequencer_text_font_load when trying to render a sequence with a text strip that has it's font changed. Debug build will crash, release build will ignore the assert and continue without any issues. Not sure if this is a bug or BLI_asserts are somehow optional.

Exact steps for others to reproduce the error

Open VSE
Add text strip
Change strip font
Render (image will do)
Result: Debug build will crash, release build will ignore the assert and work fine.

Stack Trace (ucrtbased.dll thread)

ucrtbased.dll!00007ffccd9a7135() (Unknown Source:0)
ucrtbased.dll!00007ffccd9a72d3() (Unknown Source:0)
ucrtbased.dll!00007ffccd9bbf3d() (Unknown Source:0)
blender.exe!BKE_sequencer_text_font_load(TextVars * data, const bool do_id_user) Line 3799 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\seqeffects.c:3799)
blender.exe!copy_text_effect(Sequence * dst, Sequence * src, const int flag) Line 3830 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\seqeffects.c:3830)
blender.exe!seq_dupli(const Scene * scene_src, Scene * scene_dst, ListBase * new_seq_list, Sequence * seq, int dupe_flag, const int flag) Line 5718 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\sequencer.c:5718)
blender.exe!BKE_sequence_base_dupli_recursive(const Scene * scene_src, Scene * scene_dst, ListBase * nseqbase, const ListBase * seqbase, int dupe_flag, const int flag) Line 5824 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\sequencer.c:5824)
blender.exe!scene_copy_data(Main * bmain, ID * id_dst, const ID * id_src, const int flag) Line 321 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\scene.c:321)
blender.exe!BKE_id_copy_ex(Main * bmain, const ID * id, ID * * r_newid, const int flag) Line 589 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\lib_id.c:589)
blender.exe!DEG::`anonymous namespace'::scene_copy_inplace_no_main(const Scene * scene, Scene * new_scene) Line 314 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:314)
blender.exe!DEG::deg_expand_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node, DEG::DepsgraphNodeBuilder * node_builder, bool create_placeholders) Line 881 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:881)
blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Line 953 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:953)
blender.exe!DEG::`anonymous namespace'::depsgraph_ensure_view_layer(DEG::Depsgraph * graph) Line 353 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval.cc:353)
blender.exe!DEG::deg_evaluate_on_refresh(DEG::Depsgraph * graph) Line 377 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval.cc:377)
blender.exe!DEG_evaluate_on_framechange(Main * bmain, Depsgraph * graph, float ctime) Line 84 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\depsgraph_eval.cc:84)
blender.exe!render_update_depsgraph(Render * re) Line 1991 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:1991)
blender.exe!render_init_depsgraph(Render * re) Line 2008 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:2008)
blender.exe!RE_RenderFrame(Render * re, Main * bmain, Scene * scene, ViewLayer * single_layer, Object * camera_override, int frame, const bool write_still) Line 2037 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:2037)
blender.exe!render_startjob(void * rjv, short * stop, short * do_update, float * progress) Line 679 (%BLENDER_SOURCE%\blender\source\blender\editors\render\render_internal.c:679)
blender.exe!do_job_thread(void * job_v) Line 397 (%BLENDER_SOURCE%\blender\source\blender\windowmanager\intern\wm_jobs.c:397)

**System Information** Operating system: Windows-10-10.0.14393-SP0 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19 **Blender Version** Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-04-17 09:30, hash: `40d90456ea` Worked: unknown **Short description of error** On Windows VSE fails the `BLI_assert(BLI_thread_is_main())` assert at `BKE_sequencer_text_font_load` when trying to render a sequence with a text strip that has it's font changed. Debug build will crash, release build will ignore the assert and continue without any issues. Not sure if this is a bug or `BLI_assert`s are somehow optional. **Exact steps for others to reproduce the error** 1. Open VSE 2. Add text strip 3. Change strip font 4. Render (image will do) Result: Debug build will crash, release build will ignore the assert and work fine. **Stack Trace** (ucrtbased.dll thread) ``` ucrtbased.dll!00007ffccd9a7135() (Unknown Source:0) ucrtbased.dll!00007ffccd9a72d3() (Unknown Source:0) ucrtbased.dll!00007ffccd9bbf3d() (Unknown Source:0) blender.exe!BKE_sequencer_text_font_load(TextVars * data, const bool do_id_user) Line 3799 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\seqeffects.c:3799) blender.exe!copy_text_effect(Sequence * dst, Sequence * src, const int flag) Line 3830 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\seqeffects.c:3830) blender.exe!seq_dupli(const Scene * scene_src, Scene * scene_dst, ListBase * new_seq_list, Sequence * seq, int dupe_flag, const int flag) Line 5718 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\sequencer.c:5718) blender.exe!BKE_sequence_base_dupli_recursive(const Scene * scene_src, Scene * scene_dst, ListBase * nseqbase, const ListBase * seqbase, int dupe_flag, const int flag) Line 5824 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\sequencer.c:5824) blender.exe!scene_copy_data(Main * bmain, ID * id_dst, const ID * id_src, const int flag) Line 321 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\scene.c:321) blender.exe!BKE_id_copy_ex(Main * bmain, const ID * id, ID * * r_newid, const int flag) Line 589 (%BLENDER_SOURCE%\blender\source\blender\blenkernel\intern\lib_id.c:589) blender.exe!DEG::`anonymous namespace'::scene_copy_inplace_no_main(const Scene * scene, Scene * new_scene) Line 314 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:314) blender.exe!DEG::deg_expand_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node, DEG::DepsgraphNodeBuilder * node_builder, bool create_placeholders) Line 881 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:881) blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Line 953 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval_copy_on_write.cc:953) blender.exe!DEG::`anonymous namespace'::depsgraph_ensure_view_layer(DEG::Depsgraph * graph) Line 353 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval.cc:353) blender.exe!DEG::deg_evaluate_on_refresh(DEG::Depsgraph * graph) Line 377 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\eval\deg_eval.cc:377) blender.exe!DEG_evaluate_on_framechange(Main * bmain, Depsgraph * graph, float ctime) Line 84 (%BLENDER_SOURCE%\blender\source\blender\depsgraph\intern\depsgraph_eval.cc:84) blender.exe!render_update_depsgraph(Render * re) Line 1991 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:1991) blender.exe!render_init_depsgraph(Render * re) Line 2008 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:2008) blender.exe!RE_RenderFrame(Render * re, Main * bmain, Scene * scene, ViewLayer * single_layer, Object * camera_override, int frame, const bool write_still) Line 2037 (%BLENDER_SOURCE%\blender\source\blender\render\intern\source\pipeline.c:2037) blender.exe!render_startjob(void * rjv, short * stop, short * do_update, float * progress) Line 679 (%BLENDER_SOURCE%\blender\source\blender\editors\render\render_internal.c:679) blender.exe!do_job_thread(void * job_v) Line 397 (%BLENDER_SOURCE%\blender\source\blender\windowmanager\intern\wm_jobs.c:397) ```

Vincent Blankfield commented

2020-04-17 12:11:47 +02:00

Added subscriber: @VincentBlankfield

Germano Cavalcante commented

2020-04-17 15:52:33 +02:00

Added subscribers: @iss, @mano-wii

Germano Cavalcante commented

2020-04-17 15:52:33 +02:00

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

Germano Cavalcante commented

2020-04-17 15:52:33 +02:00

I can confirm.
The assert was introduced in b3dbe176

I can confirm. The assert was introduced in b3dbe176

Chris Shedd commented

2020-06-01 19:57:20 +02:00

Added subscriber: @F0Burny

Chris Shedd commented

2020-06-01 19:57:20 +02:00

This comment was removed by @F0Burny

*This comment was removed by @F0Burny*

Richard Antalik commented

2020-06-01 20:03:23 +02:00

In #75822#942282, @F0Burny wrote:
Blender crashes by pressing "G" then moving the vertices in edit mode.

Per the instructions at https://youtube.com/watch?v=RaT-uGSwgUw

Blender version 2.82 // Running on Kali-Linux x86-64

The error is as follows as it Aborts: (this is seen if Blender is run from the terminal)

blender(BLI_system_backtrace+0x33) [0x559180ab50b3]
blender(trans_mesh_customdata_correction_init+0x39f) [0x55917ec0c7ef]
blender(+0x1b07c04) [0x55917ebf2c04]
blender(transformEvent+0xeaa) [0x55917ebf7bfa]
blender(+0x1b35568) [0x55917ec20568]
blender(+0x15c215a) [0x55917e6ad15a]
blender(+0x15c2f44) [0x55917e6adf44]
blender(+0x15c4b6c) [0x55917e6afb6c]
blender(wm_event_do_handlers+0x50d) [0x55917e6b03ed]
blender(WM_main+0x20) [0x55917e6a5a60]
blender(main+0x2ae) [0x55917e48046e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3263c16e0b]
blender(_start+0x2a) [0x55917e4cc3ba]
BLI_assert failed: /build/blender-TGY4wC/blender-2.82.a+dfsg/source/blender/editors/transform/transform_convert_mesh.c:1033, trans_mesh_customdata_correction_init(), at 'tc->custom.type.data == ((void *)0)'
Aborted

This has nothing to do with this report.

Please submit new report if you want to report bug https://developer.blender.org/maniphest/task/edit/form/2/

> In #75822#942282, @F0Burny wrote: > Blender crashes by pressing "G" then moving the vertices in edit mode. > > Per the instructions at https://youtube.com/watch?v=RaT-uGSwgUw > > Blender version 2.82 // Running on Kali-Linux x86-64 > > The error is as follows as it Aborts: (this is seen if Blender is run from the terminal) > > blender(BLI_system_backtrace+0x33) [0x559180ab50b3] > blender(trans_mesh_customdata_correction_init+0x39f) [0x55917ec0c7ef] > blender(+0x1b07c04) [0x55917ebf2c04] > blender(transformEvent+0xeaa) [0x55917ebf7bfa] > blender(+0x1b35568) [0x55917ec20568] > blender(+0x15c215a) [0x55917e6ad15a] > blender(+0x15c2f44) [0x55917e6adf44] > blender(+0x15c4b6c) [0x55917e6afb6c] > blender(wm_event_do_handlers+0x50d) [0x55917e6b03ed] > blender(WM_main+0x20) [0x55917e6a5a60] > blender(main+0x2ae) [0x55917e48046e] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3263c16e0b] > blender(_start+0x2a) [0x55917e4cc3ba] > BLI_assert failed: /build/blender-TGY4wC/blender-2.82.a+dfsg/source/blender/editors/transform/transform_convert_mesh.c:1033, trans_mesh_customdata_correction_init(), at 'tc->custom.type.data == ((void *)0)' > Aborted This has nothing to do with this report. Please submit new report if you want to report bug https://developer.blender.org/maniphest/task/edit/form/2/

Antonio Ospite commented

2020-06-01 23:40:19 +02:00

Added subscriber: @ao2

Antonio Ospite commented

2020-06-01 23:40:19 +02:00

FYI the original bug about text strips can be reproduced with the blender 2.82.a binary shipped in Debian unstable:

blender(BLI_system_backtrace+0x33) [0x561f8b20d0b3]
blender(BKE_sequencer_text_font_load+0xce) [0x561f88def58e]
blender(+0x14d31c0) [0x561f88d161c0]
blender(BKE_sequence_base_dupli_recursive+0x85) [0x561f88d17555]
blender(BKE_scene_copy_data+0x2dc) [0x561f88d0858c]
blender(BKE_id_copy_ex+0x6b1) [0x561f88c6fdc1]
blender(+0x1d10b34) [0x561f89553b34]
blender(_ZN3DEG34deg_expand_copy_on_write_datablockEPKNS_9DepsgraphEPKNS_6IDNodeEPNS_20DepsgraphNodeBuilderEb+0x413) [0x561f89554453]
blender(_ZN3DEG34deg_update_copy_on_write_datablockEPKNS_9DepsgraphEPKNS_6IDNodeE+0x98) [0x561f89554c58]
blender(_ZN3DEG23deg_evaluate_on_refreshEPNS_9DepsgraphE+0x97) [0x561f89553577]
blender(DEG_evaluate_on_framechange+0x64) [0x561f89539e54]
blender(+0x34037fa) [0x561f8ac467fa]
blender(+0x3403878) [0x561f8ac46878]
blender(RE_RenderAnim+0x120) [0x561f8ac4ad20]
blender(+0x233ad3c) [0x561f89b7dd3c]
blender(+0x15ced22) [0x561f88e11d22]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8f27) [0x7f7be9d41f27]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f7be526531f]
BLI_assert failed: /build/blender-TGY4wC/blender-2.82.a+dfsg/source/blender/blenkernel/intern/seqeffects.c:3824, BKE_sequencer_text_font_load(), at 'BLI_thread_is_main()'
Annullato

I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here?

I can attach a minimal reproducing .blend if necessary, but other devs may not have the same fonts as me.

Thanks, Antonio

FYI the original bug about text strips can be reproduced with the blender 2.82.a binary shipped in Debian unstable: ``` blender(BLI_system_backtrace+0x33) [0x561f8b20d0b3] blender(BKE_sequencer_text_font_load+0xce) [0x561f88def58e] blender(+0x14d31c0) [0x561f88d161c0] blender(BKE_sequence_base_dupli_recursive+0x85) [0x561f88d17555] blender(BKE_scene_copy_data+0x2dc) [0x561f88d0858c] blender(BKE_id_copy_ex+0x6b1) [0x561f88c6fdc1] blender(+0x1d10b34) [0x561f89553b34] blender(_ZN3DEG34deg_expand_copy_on_write_datablockEPKNS_9DepsgraphEPKNS_6IDNodeEPNS_20DepsgraphNodeBuilderEb+0x413) [0x561f89554453] blender(_ZN3DEG34deg_update_copy_on_write_datablockEPKNS_9DepsgraphEPKNS_6IDNodeE+0x98) [0x561f89554c58] blender(_ZN3DEG23deg_evaluate_on_refreshEPNS_9DepsgraphE+0x97) [0x561f89553577] blender(DEG_evaluate_on_framechange+0x64) [0x561f89539e54] blender(+0x34037fa) [0x561f8ac467fa] blender(+0x3403878) [0x561f8ac46878] blender(RE_RenderAnim+0x120) [0x561f8ac4ad20] blender(+0x233ad3c) [0x561f89b7dd3c] blender(+0x15ced22) [0x561f88e11d22] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8f27) [0x7f7be9d41f27] /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f7be526531f] BLI_assert failed: /build/blender-TGY4wC/blender-2.82.a+dfsg/source/blender/blenkernel/intern/seqeffects.c:3824, BKE_sequencer_text_font_load(), at 'BLI_thread_is_main()' Annullato ``` I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here? I can attach a minimal reproducing .blend if necessary, but other devs may not have the same fonts as me. Thanks, Antonio

Richard Antalik commented

2020-06-01 23:59:37 +02:00

In #75822#942340, @ao2 wrote:
I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here?

I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already.

Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority.

> In #75822#942340, @ao2 wrote: > I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here? I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already. Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority.

Antonio Ospite commented

2020-06-02 00:24:05 +02:00

In #75822#942342, @iss wrote:

In #75822#942340, @ao2 wrote:
I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here?

I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already.

Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority.

I intended to post to Debian tracker to ask two things:

why the binary crashes as at all: is Debian shipping a debug build?
possibly integrate the fix as a patch in case waiting for the next upstream including it takes too long.

Does that make sense?

Thanks, Antonio

> In #75822#942342, @iss wrote: >> In #75822#942340, @ao2 wrote: >> I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here? > I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already. > > Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority. I intended to post to Debian tracker to ask two things: 1. why the binary crashes as at all: is Debian shipping a debug build? 2. possibly integrate the fix as a patch in case waiting for the next upstream including it takes too long. Does that make sense? Thanks, Antonio

Richard Antalik commented

2020-06-02 00:56:32 +02:00

Added subscriber: @Sergey

Richard Antalik commented

2020-06-02 00:56:32 +02:00

In #75822#942360, @ao2 wrote:

In #75822#942342, @iss wrote:

In #75822#942340, @ao2 wrote:
I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here?

I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already.

Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority.

I intended to post to Debian tracker to ask two things:

why the binary crashes as at all: is Debian shipping a debug build?

I am not sure if they would be able to answer this though. Perhaps it would be better asking our platform maintainer - assert shouldn't crash non-debug build AFAIK. I am not able to test this really unfortunately, but this may be bug on it's own. Can you bring some light on this @Sergey?

possibly integrate the fix as a patch in case waiting for the next upstream including it takes too long.

I am not sure how this would work as well. There are number of fixes daily, many of them "more important" than this fix would be.

In any case if this is in scope of Debian bugtracker go ahead.

> In #75822#942360, @ao2 wrote: >> In #75822#942342, @iss wrote: >>> In #75822#942340, @ao2 wrote: >>> I will report on the Debian bug tracker too, but maybe this is enough to bring the priority back to high here? >> I don't think you need to report this to Debian tracker. it's Blender bug and it's being handled here already. >> >> Unless this is crashing regular release (not debug) builds, I don't see reason to increase priority. > > I intended to post to Debian tracker to ask two things: > > 1. why the binary crashes as at all: is Debian shipping a debug build? I am not sure if they would be able to answer this though. Perhaps it would be better asking our platform maintainer - assert shouldn't crash non-debug build AFAIK. I am not able to test this really unfortunately, but this may be bug on it's own. Can you bring some light on this @Sergey? > 2. possibly integrate the fix as a patch in case waiting for the next upstream including it takes too long. I am not sure how this would work as well. There are number of fixes daily, many of them "more important" than this fix would be. In any case if this is in scope of Debian bugtracker go ahead.

Sergey Sharybin commented

2020-06-02 12:02:25 +02:00

Looking at the build logs - [x] it seems that the dh builder script passed build type of None. This makes it so release-specific flags are not appended to the common CFLAGS, resulting to NDEBUG not defined, which makes asserts() to run. Please submit this issue to the Debian BTS.

https://buildd.debian.org/status/fetch.php?pkg=blender&arch=amd64&ver=2.82.a%2Bdfsg-1%2Bb2&stamp=1589232944&raw=0

Looking at the build logs - [x] it seems that the dh builder script passed build type of None. This makes it so release-specific flags are not appended to the common `CFLAGS`, resulting to `NDEBUG` not defined, which makes `asserts()` to run. Please submit this issue to the Debian BTS. - [x] https://buildd.debian.org/status/fetch.php?pkg=blender&arch=amd64&ver=2.82.a%2Bdfsg-1%2Bb2&stamp=1589232944&raw=0

Antonio Ospite commented

2020-06-03 00:18:52 +02:00

In #75822#942660, @Sergey wrote:
Looking at the build logs - [x] it seems that the dh builder script passed build type of None. This makes it so release-specific flags are not appended to the common CFLAGS, resulting to NDEBUG not defined, which makes asserts() to run. Please submit this issue to the Debian BTS.

https://buildd.debian.org/status/fetch.php?pkg=blender&arch=amd64&ver=2.82.a%2Bdfsg-1%2Bb2&stamp=1589232944&raw=0

Thank you for the initial investigation @sergey.

I filed the Debian report with a little more background and asked for the opinion of the Debian maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962074

> In #75822#942660, @Sergey wrote: > Looking at the build logs - [x] it seems that the dh builder script passed build type of None. This makes it so release-specific flags are not appended to the common `CFLAGS`, resulting to `NDEBUG` not defined, which makes `asserts()` to run. Please submit this issue to the Debian BTS. > > - [x] https://buildd.debian.org/status/fetch.php?pkg=blender&arch=amd64&ver=2.82.a%2Bdfsg-1%2Bb2&stamp=1589232944&raw=0 Thank you for the initial investigation @sergey. I filed the Debian report with a little more background and asked for the opinion of the Debian maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962074

Thomas Dinges added this to the 2.93 LTS milestone 2023-02-07 18:40:57 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE: BLI_assert fails while rendering strip with changed font #75822