I tried to compile CinGG with all your patches except 0007. All OK. I started CinGG without any problems, but I haven't done any tests yet.

вс, 12 февр. 2023 г., 02:02 Phyllis Smith <[email protected]>:

*Checked into GIT, the following 4:* 0002-Missing-returns-in-videowindow.C.patch 0003-missing-returns-in-videowindowgui.C.patch 0004-Missing-return-in-videoconfig.C.patch 0012-Add-patch-from-ffmpeg-5.1-branch-hopefully-fix-build.patch

As proven by Andrea, it now builds with Vulkan and does not need (it looks like Andrea found this bug before they did): 0007-Disable-vulkan-in-embedded-ffmpeg.patch

Tested with no result with auto all fits on Fedora 32 only and planning on testing next on Fedora 37: 0010-TMP-add-flto-to-cinelerra-Makefile.patch How do I test this?: 0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch

well, in theory (I hoped) 0010 should trigger crash on "auto fit autos" and 0011 should fix it. But because it does not crash for me on termux and I not tested it on desktop Slackware yet ... whole thing might be moving in wrong direction. After applying 0010 you should notice much longer linking time. But hopefully better performance.

Need further testing yet: 0005-noexecstack-by-default-in-cinelerra-Makefile.patch 0008-Add-with-gnu-debuglink-to-cinelerra-Makefile.patch 0009-Default-atrack-vtrack-to-64-in-localsession.patch

Forgot how to fix this to check into GIT but will figure it out myself: 0006-D-build-fixes.patch

Clang patch was too big to attach, but I already have the one dated Jul 24, 2022 called "0003-Add-x265-patch-for-aarch64-clang.patch". Is this correct? or could you send me "0001-Add-x265-patch-for-aarch64-clang.patch" privately so I make sure it has not changed?

I'll resend it privately just in case.

On Thu, Feb 9, 2023 at 11:29 AM Andrew Randrianasulu < [email protected]> wrote:

...

I have those in my termux tree

09feb2022/0001-Add-x265-patch-for-aarch64-clang.patch

big one (186 kb), needed for clang compile on arm64/termux

09feb2022/0002-Missing-returns-in-videowindow.C.patch

09feb2022/0003-missing-returns-in-videowindowgui.C.patch

09feb2022/0004-Missing-return-in-videoconfig.C.patch

not really hot, those files apparently not even compiled for now!

09feb2022/0005-noexecstack-by-default-in-cinelerra-Makefile.patch

obvious from name

09feb2022/0006-D-build-fixes.patch

for some reason netbsd.bld not executable by default, should we make it so?

09feb2022/0007-Disable-vulkan-in-embedded-ffmpeg.patch

hopefully not needed after 0012

09feb2022/0008-Add-with-gnu-debuglink-to-cinelerra-Makefile.patch

incomplete, I missed same thing with bdwrite

09feb2022/0009-Default-atrack-vtrack-to-64-in-localsession.patch

our openEDL on viewer-created clip fix

09feb2022/0010-TMP-add-flto-to-cinelerra-Makefile.patch

localhack, trying to make it crash on "fit all autos" like in Fedora, no luck so far!

09feb2022/0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch

try to prevent said crash

09feb2022/0012-Add-patch-from-ffmpeg-5.1-branch-hopefully-fix-build.patch

picked up from ffmpeg.git 5.1 branch, compile-tested

вс, 12 февр. 2023 г., 04:17 Phyllis Smith <[email protected]>:

...

...

Tested with no result with auto all fits on Fedora 32 only and planning on testing next on Fedora 37: 0010-TMP-add-flto-to-cinelerra-Makefile.patch How do I test this?: 0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch

well, in theory (I hoped) 0010 should trigger crash on "auto fit autos" and 0011 should fix it. But because it does not crash for me on termux and I not tested it on desktop Slackware yet ... whole thing might be moving in wrong direction.

Thanks for the explanation. I have booted Fedora 37 (because that is where it crashed for Jin) and built it using 0010 with the added flto flag. It still does not crash. I no longer have Fedora 36 available and am not planning on getting it back. Without being able to reproduce the crash, it really is practically impossible to fix. I suspect you already looked at their reported compilation flags, but I will try some of their more weird ones if I can figure out how (like -Werror=format-security) which must be like how you added -flto. Stay tuned.

May be you need flto added also to guicast Makefile because we link it in statically ...

Bugs, bugs, bugs -- they seem to be everywhere. Adding -flto to guicast Makefile did not create the error either. I will have to test more tomorrow as getting too tired. 1) Also, sent email about "command not found" in log: [DEP] vp8/common/x86/iwalsh_sse2.asm.d -- Performing Test WEBP_HAVE_FLAG_MSA - Failed -- Performing Test WEBP_HAVE_FLAG_MSA config.status: creating config.h yes g++ -E no checking altivec.h presence... checking for lrint... gcc3 *./configure: line 4399: AX_CXX_COMPILE_STDCXX_11: command not found* autoreconf: running: automake --add-missing --copy --force-missing config.status: creating doc/Doxyfile [DEP] vp8/common/x86/loopfilter_sse2.asm.d config.status: executing depfiles commands checking build system type... -- Performing Test C_FLAG_SUPPORTED - Success Checking C++ compiler flag support for: -Wextra-semi 2) and if you are not already busy enough! do you have any ideas about https://www.cinelerra-gg.org/bugtracker/view.php?id=633 Andrew, sorry for keeping you so busy and not being more helpful. On Sat, Feb 11, 2023 at 6:22 PM Andrew Randrianasulu < [email protected]> wrote:

вс, 12 февр. 2023 г., 04:17 Phyllis Smith <[email protected]>:

...

...

...

Tested with no result with auto all fits on Fedora 32 only and planning on testing next on Fedora 37: 0010-TMP-add-flto-to-cinelerra-Makefile.patch How do I test this?: 0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch

well, in theory (I hoped) 0010 should trigger crash on "auto fit autos" and 0011 should fix it. But because it does not crash for me on termux and I not tested it on desktop Slackware yet ... whole thing might be moving in wrong direction.

Thanks for the explanation. I have booted Fedora 37 (because that is where it crashed for Jin) and built it using 0010 with the added flto flag. It still does not crash. I no longer have Fedora 36 available and am not planning on getting it back. Without being able to reproduce the crash, it really is practically impossible to fix. I suspect you already looked at their reported compilation flags, but I will try some of their more weird ones if I can figure out how (like -Werror=format-security) which must be like how you added -flto. Stay tuned.

May be you need flto added also to guicast Makefile because we link it in statically ...

...

Andrew, catching up on some email questions while testing some patches: 2) and if you are not already busy enough! do you have any ideas about

...

https://www.cinelerra-gg.org/bugtracker/view.php?id=633

... was it regression?

No, this has always existed. We never tested using it with audio like Stefan did so apparently it never worked.

вт, 14 февр. 2023 г., 21:18 Phyllis Smith <[email protected]>:

Checked into GIT the following either yesterday or today:

On Thu, Feb 9, 2023 at 11:29 AM Andrew Randrianasulu < [email protected]> wrote:

...

I have those in my termux tree

09feb2022/0001-Add-x265-patch-for-aarch64-clang.patch

big one (186 kb), needed for clang compile on arm64/termux

*The above is now checked in.*

but with wrong name? thirdparty/src/x265_3.5.patch0 it must be named same as base source tarball. After rebase I have two patches: -rw------- 1 u0_a204 u0_a204 180366 Feb 14 22:18 thirdparty/src/x265_3.5.patch0 -rw------- 1 u0_a204 u0_a204 993352 Mar 27 2022 thirdparty/src/x265_3.5.tar.xz -rw------- 1 u0_a204 u0_a204 180366 Feb 14 22:18 thirdparty/src/x265_3_5.patch0 note 3.5 vs 3_5 guess you can just rename patch somehow? Or delete, commit, add with new name, commit, push. Also, tiff-4.3.0 probably can go away now? ...

...

09feb2022/0006-D-build-fixes.patch

for some reason netbsd.bld not executable by default, should we make it so?

*The above is now checked in* (twice since I did it wrong initially).

...

ср, 15 февр. 2023 г., 04:39 Phyllis Smith <[email protected]>:

*Typo. Now fixed as described below. I never used to make so many mistakes* <[email protected]>

...

...

...

09feb2022/0001-Add-x265-patch-for-aarch64-clang.patch

big one (186 kb), needed for clang compile on arm64/termux

*The above is now checked in.*

but with wrong name?

thirdparty/src/x265_3.5.patch0

it must be named same as base source tarball.

After rebase I have two patches:

-rw------- 1 u0_a204 u0_a204 180366 Feb 14 22:18 thirdparty/src/x265_3.5.patch0 -rw------- 1 u0_a204 u0_a204 993352 Mar 27 2022 thirdparty/src/x265_3.5.tar.xz -rw------- 1 u0_a204 u0_a204 180366 Feb 14 22:18 thirdparty/src/x265_3_5.patch0

note 3.5 vs 3_5

guess you can just rename patch somehow? Or delete, commit, add with new name, commit, push.

Also, tiff-4.3.0 probably can go away now?

*Deleted as recommended both the tar and its patch as well as previous **flac 1.3.2 version.*

*Also, minor test of **0008-Add-with-gnu-debuglink-to-cinelerra-Makefile.patch also checked into GIT.*

build ok on termux, while speed for 2.5k video still not stellar: Cinelerra Infinity - built: Feb 15 2023 05:36:29 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. x265 [info]: HEVC encoder version 3.5+1-f0c1022b6 x265 [info]: build info [Linux][clang 15.0.7][64 bit] 8bit x265 [info]: using cpu capabilities: NEON x265 [info]: Main profile, Level-5 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(24 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3 x265 [info]: Keyframe min / max / scenecut / bias : 30 / 30 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-5.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp x265 [info]: tools: b-intra strong-intra-smoothing lslices=8 deblock sao x265 [info]: frame I: 10, Avg QP:5.84 kb/s: 122708.30 x265 [info]: frame P: 41, Avg QP:6.32 kb/s: 108553.34 x265 [info]: frame B: 133, Avg QP:9.14 kb/s: 57693.48 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 11.8% 0.0% 23.5% 45.1% 19.6% encoded 184 frames in 571.71s (0.32 fps), 72559.80 kb/s, Avg QP:8.34 Render::render_single: Session finished. ** rendered 184 frames in 572.422 secs, 0.321 fps AudioPulse::open_output 110: failed server=(null) Connection refused AudioPulse::open_output 110: failed server=(null) Connection refused Total excess of backups: -50 Session time: 0:14:50 Cpu time: user: 1:08:59.945 sys: 0:00:59.933 unjoined tids / owner 1 000000730dc68d00 / 0000007308938d00 12RenderEngine ====

Andrew, Can now reproduce the "auto fit" crash reliably on Fedora 37 when add to CFLAGS in cinelerra/Makefile "-flto -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" and on Fedora 36 under different circumstances, which is CFLAGS addition of "-O2 -flto". Not sure why different CFLAGS are required on different O/S versions. Anyway I get the same crash backtrace of: (gdb) bt #0 0x0000000000a0cad0 in Autos::get_next_auto(long, int, Auto*&, int) () #1 0x0000000000b04dde in FloatAutos::get_value(long, int, FloatAuto*&, FloatAuto*&) () #2 0x0000000000b0530e in FloatAutos::get_extents(float*, float*, int*, long, long) () #3 0x0000000000a0ae14 in Automation::get_extents(float*, float*, int*, long, long, int) () #4 0x0000000000c5d092 in Tracks::get_automation_extents(float*, float*, double, double, int) () #5 0x0000000000b6a30d in MWindow::fit_autos(int) () #6 0x0000000000a9f8c9 in EditFitAutos::handle_event() () #7 0x0000000000cebbf4 in BC_Button::button_release_event() () #8 0x0000000000d310fb in BC_WindowBase::dispatch_button_release() () #9 0x0000000000d310fb in BC_WindowBase::dispatch_button_release() () #10 0x0000000000d399ff in BC_WindowBase::dispatch_event() () #11 0x0000000000d3a288 in BC_WindowBase::run_window() () #12 0x0000000000b751bf in MWindow::run() () #13 0x00000000007f41be in main () But the PROBLEM is when I add a printf statement, it no longer crashes. And when I compile to add a symbol table to use with GDB, it no longer crashes. Applying the patch: 0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch, still crashes too. Any advice of how I can debug further? How can I view the value of variables in GDB without a symbol table? On Wed, Feb 15, 2023 at 6:29 PM Phyllis Smith <[email protected]> wrote:

...

09feb2022/0010-TMP-add-flto-to-cinelerra-Makefile.patch

localhack, trying to make it crash on "fit all autos" like in Fedora, no luck so far!

Working again on trying to reproduce this on Fedora 37 with default installed gcc. Patched file with this + added LINKER = ld +flto to the cinelerra/Makefile because read onlinethat flto has to be added to the compiler AND the linker. But still no crash with "fit all autos".

According to the RPM Fusion bug comment as quoted below, when they removed the lto, the crash was fixed.

I saw the https://www.cinelerra-gg.org/bugtracker/view.php?id=632 mentioned lto, so I've tested and disabled lto on the build and now I'm not reproducing the issue. But it would be fine if a dedicated issue can be created so that cinelerra can work with lto...

So I still have to find a way to make it crash, so a fix can be created. Will update when I succeed.

пт, 10 мар. 2023 г., 02:02 Phyllis Smith <[email protected]>:

Andrew, Can now reproduce the "auto fit" crash reliably on Fedora 37 when add to CFLAGS in cinelerra/Makefile "-flto -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" and on Fedora 36 under different circumstances, which is CFLAGS addition of "-O2 -flto". Not sure why different CFLAGS are required on different O/S versions.

Anyway I get the same crash backtrace of: (gdb) bt #0 0x0000000000a0cad0 in Autos::get_next_auto(long, int, Auto*&, int) () #1 0x0000000000b04dde in FloatAutos::get_value(long, int, FloatAuto*&, FloatAuto*&) () #2 0x0000000000b0530e in FloatAutos::get_extents(float*, float*, int*, long, long) () #3 0x0000000000a0ae14 in Automation::get_extents(float*, float*, int*, long, long, int) () #4 0x0000000000c5d092 in Tracks::get_automation_extents(float*, float*, double, double, int) () #5 0x0000000000b6a30d in MWindow::fit_autos(int) () #6 0x0000000000a9f8c9 in EditFitAutos::handle_event() () #7 0x0000000000cebbf4 in BC_Button::button_release_event() () #8 0x0000000000d310fb in BC_WindowBase::dispatch_button_release() () #9 0x0000000000d310fb in BC_WindowBase::dispatch_button_release() () #10 0x0000000000d399ff in BC_WindowBase::dispatch_event() () #11 0x0000000000d3a288 in BC_WindowBase::run_window() () #12 0x0000000000b751bf in MWindow::run() () #13 0x00000000007f41be in main ()

But the PROBLEM is when I add a printf statement, it no longer crashes. And when I compile to add a symbol table to use with GDB, it no longer crashes. Applying the patch: 0011-EXPERIMENTAL-try-to-init-two-variables-to-0-in-gloat.patch, still crashes too. Any advice of how I can debug further? How can I view the value of variables in GDB without a symbol table?

:( worst type of bug - probably some thread synchronization issue, timing-sensitive :/ but at least we know now that my patch is no cure :| Thanks anyway .... I have no idea if gdb can print something it has no idea how to name. try tip from https://sourceware.org/gdb/onlinedocs/gdb/Variables.html ==== If you try to examine or use the value of a (global) variable for which GDB has no type information, e.g., because the program includes no debug information, GDB displays an error message. See unknown type <https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html#Symbols>, for more about unknown types. If you cast the variable to its declared type, GDB gets the variable’s value using the cast-to type as the variable’s type. For example, in a C program: (gdb) p var 'var' has unknown type; cast it to its declared type (gdb) p (float) var $1 = 3.14 =====

On Wed, Feb 15, 2023 at 6:29 PM Phyllis Smith <[email protected]> wrote:

...

...

09feb2022/0010-TMP-add-flto-to-cinelerra-Makefile.patch

localhack, trying to make it crash on "fit all autos" like in Fedora, no luck so far!

Working again on trying to reproduce this on Fedora 37 with default installed gcc. Patched file with this + added LINKER = ld +flto to the cinelerra/Makefile because read onlinethat flto has to be added to the compiler AND the linker. But still no crash with "fit all autos".

According to the RPM Fusion bug comment as quoted below, when they removed the lto, the crash was fixed.

I saw the https://www.cinelerra-gg.org/bugtracker/view.php?id=632 mentioned lto, so I've tested and disabled lto on the build and now I'm not reproducing the issue. But it would be fine if a dedicated issue can be created so that cinelerra can work with lto...

So I still have to find a way to make it crash, so a fix can be created. Will update when I succeed.