View Issue Details

IDProjectCategoryView StatusLast Update
0000547Cinelerra-GG[All Projects] Bugpublic2021-03-02 17:48
ReporterAndrew-R Assigned ToPhyllisSmith  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2020-08 
Target VersionFixed in Version 
Summary0000547: Background rendering segfault
DescriptionSorry, it may sounds like my other bug, but I think this is new one ...


If i set video output to X11-direct, and background render to jpeg, enable it in prefs and then hit Shift-G - it encodes all files, but attempt at playback result in crash/backtrace :(

Steps To ReproduceSet video output to x11-direct - it works in X11-Opengl/Xv/non-direct
Configure background render whit jpeg video codec
Load video
Try to enable background render (from menu of Shift-G)

Try to play forward.

You observe crash .... (I think)

May be related to my arch/OS (Slackware 32-bit, clang-10 as compiler)
Additional InformationBacktrace:

Thread 88 "cin" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xcef93b40 (LWP 30075)]
0x08864c73 in BC_Xfer::xfer_yuv420p_to_bgr8888(unsigned int, unsigned int) ()
(gdb) bt full
#0 0x08864c73 in BC_Xfer::xfer_yuv420p_to_bgr8888(unsigned int, unsigned int) ()
No symbol table info available.
0000001 0x08804e70 in BC_Xfer::xfer_slices(int) ()
No symbol table info available.
0000002 0x08805695 in BC_CModels::transfer(unsigned char**, unsigned char**, unsigned char*, unsigned char*, unsigned char*, unsigned char*, unsigned char*, unsigned char*, int, int, int, int, int, int, int, int, int, int, int, int, int) ()
No symbol table info available.
0000003 0x085c7c0e in mjpeg_decompress ()
No symbol table info available.
#4 0x0858668d in FileJPEG::read_frame(VFrame*, VFrame*) ()
No symbol table info available.
0000005 0x08587c96 in FileList::read_frame(VFrame*) ()
No symbol table info available.
0000006 0x0858ac5b in File::read_frame(VFrame*, int) ()
No symbol table info available.
0000007 0x08714d84 in VRender::process_buffer(long long, int) ()
No symbol table info available.
0000008 0x087151a2 in VRender::run() ()
No symbol table info available.
#9 0x087f6251 in Thread::entrypoint(void*) ()
No symbol table info available.
0000010 0xf7bdef66 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
0000011 0xf67b4c36 in clone () from /lib/libc.so.6
No symbol table info available.
(gdb) quit
A debugging session is active.

        Inferior 1 [process 29958] will be killed.

Quit anyway? (y or n) y
signal_entry_recoverable: got SIGPIPE my pid=30056
signal_entry_recoverable: got SIGPIPE my pid=30056
TagsNo tags attached.

Activities

PhyllisSmith

PhyllisSmith

2021-03-02 17:48

manager   ~0004661

New AppImages contain fix 20210228.
PhyllisSmith

PhyllisSmith

2021-03-01 16:16

manager   ~0004660

Fixed in the AppImages of 20210228.
PhyllisSmith

PhyllisSmith

2021-02-19 23:22

manager   ~0004652

Last edited: 2021-02-19 23:26

View 3 revisions

@Andrew-R
Your patch "fix_brender_direct_x11_jpeg.diff" did solve the problem but I was concerned that changing the colormodel would affect the results. So after 5 days of "programming by mutation" I discovered that the line in filelist.h: "int can_scale_input() { return 1; }" if changed to 0 instead, fixed the problem. BUT I do not know for sure if that will undo the "Resize bug for Filelist type assets, such as png, has been fixed." I tried to create the resize bug but did not know how to do that (tried proxy and resize track).

I based my guess on what was done in filebase.h as in the last line of the following code:

// Return either the argument or another colormodel which read_frame should
// use.
        virtual int colormodel_supported(int colormodel) { return BC_RGB888; }
// This file can copy compressed frames directly from the asset
        virtual int can_copy_from(Asset *asset, int64_t position) { return 0; }
        virtual int can_scale_input() { return 0; }

Your discovery and possible fix for this bug has finally led to a solution that "I think" is correct. X11 direct was a valuable feature provided by the original programmer to speed up certain stuff. I will mark this resolved in a couple of days. There is a new AppImage for newer distros on the website with this patch in (as well as the Autosave backps).

Andrew-R

Andrew-R

2021-02-14 04:32

reporter   ~0004636

from description, it sounds like single-frame PNG's (or other image?)' were not resizing properly? Not sure where you should set this resize . In asset window, may be?
PhyllisSmith

PhyllisSmith

2021-02-13 22:44

manager   ~0004634

@Andrew-R
The crash seems to happen when the modifications for filelist.h and filelist.C from 10/27/2020 were added. Reference is:
    "Resize bug for Filelist type assets, such as png, has been fixed."
When I back out this mod, it no longer crashes but I can not remember where this bug came from and who reported it.
And I do not know how to fix it !!
PhyllisSmith

PhyllisSmith

2021-02-13 02:01

manager   ~0004629

Been working on this again today. With cincity's xml example file from the forum, I was able to reproduce the crash. I have narrowed it down to:

Not Broken:
commit a718f58e6d8061f83bd0c0b10848ac415cd21fcd
Date: Sat Oct 24 16:21:55 2020 -0600
-- rework proxy for 1:1 and new layout, fix proxy for resized assets, change track gang_master patchbay flag use to allow disabled slaves

Broken:
commit c4c898707e3fdbf2979b7bc43ac0e1b0fa779663
Date: Tue Oct 27 16:37:06 2020 -0600
-- manual goto rework, resize asset/track tweaks and fixes, filelist resize fix, allow at least 1 vicon frame for target/src draw, update es.po

Must be somewhere in the above.
Andrew-R

Andrew-R

2021-02-11 03:09

reporter   ~0004628

is there some possibility non-english locale interferes somehow?

Also, does my patch ("fix_brender_direct_x11_jpeg.diff") helps? :}

I noticed from dump txt crashing machine also has older AMD processor - probably related? ( AMD Phenom(tm) II X4 955 Processor)
does change video output method helps?
PhyllisSmith

PhyllisSmith

2021-02-10 19:20

manager   ~0004627

@Andrew-R
Someone else is having a similar problem and I have not had a chance to reproduce the error I also had in Note 4550.
Maybe there is more information that will help in the following forum entry on this:

   https://www.cinelerra-gg.org/forum/help-video/crash-on-background-rendering/#post-1594
Andrew-R

Andrew-R

2021-01-22 09:01

reporter   ~0004567

some commands I used for "64-bit slackware installed in qemu as 64-bit chroot" (in russian but commands are all english :P)
For 32-bit thing just install/unpack 32-bit distro in some folder ....

https://www.linux.org.ru/forum/desktop/14777444
Andrew-R

Andrew-R

2021-01-22 08:56

reporter   ~0004566

@Andrea_Paz

yeah, apparently this page was deleted/archived from ArchWiki
https://www.linuxsecrets.com/archlinux-wiki/wiki.archlinux.org/index.php/Install_bundled_32-bit_system_in_64-bit_system.html

"Gnome-colors-add-files-to-archive.pngThis article is being considered for archiving.Gnome-colors-add-files-to-archive.png
Reason: https://www.archlinux.org/news/phasing-out-i686-support/"

But again, you can run any distro in chroot ... may even install on qemu/vbox and then copy content of their virtual disk to some directory and chroot in it
Old-fashioned way, I know ....

https://wiki.archlinux.org/index.php/Chroot - has some info
But if you run x86_64 kernel (like I do)
you *can* have main 32-bit system and 64-bit chroot, or main 64-bit system and 32-bit chroot. (I run multilib chroot of Rosa Linux this way)

On 32-bit kernel you can't run 64-bit userspace (at least not without things like qemu, it will be SLOW)
Andrea_Paz

Andrea_Paz

2021-01-22 08:31

manager   ~0004565

Sorry, but from the guides I've found (nothing for Arch Linux) I can't figure out how to do 32-bit chroot.
PhyllisSmith

PhyllisSmith

2021-01-21 17:16

manager   ~0004559

@Andrew-R
I am not sure that this is only a local problem because it crashed for me also BUT I think the steps I used included some step that I can not remember. I downloaded your file and tested that too without a crash. Will test some more when I get time to see if I can get it to crash again and this time I will try to be more vigilant in the steps I use.
Andrew-R

Andrew-R

2021-01-21 16:38

reporter   ~0004558

@Andrea_Paz , so most likely this is my local problem. If you have 32-bit chroot around - can you test there, too ?
Andrea_Paz

Andrea_Paz

2021-01-21 16:30

manager   ~0004557

I've done some tests and everything works normally. Sometimes I have problems with the set range, which is not respected and starts from the insertion point to the end of the timeline.
But no crashes. Here is an example of terminal output:

"
BRenderThread::start 1 map=562 equivalent=31 brender_start=31 result=31 end=211
RenderFarmClient::main_loop: Session started from /tmp/cinelerra.e01ce6ba-e919-4a06-b266-63e2cc1ecb53
RenderFarmClientThread::run: Session finished.
"
Andrew-R

Andrew-R

2021-01-19 19:20

reporter   ~0004552

@PhyllisSmith, I'm sorry for adding more load on you ......

Strangely enough it works if I load jpeg file(s) directly into timeline - only background render result in this crash for me ...
Moment, I'll upload specific sample ....

Try this file:
https://cloud.mail.ru/public/KKY8/o86j62p2z

Load it, select region, turn bg render ON, hit 'space' (play) .....For me it crashed reliably :/
May be you use X11 non-direct, or other mode? I only was able to crash it in X11-direct, but this is apparently new install default setting :/
PhyllisSmith

PhyllisSmith

2021-01-19 16:55

manager   ~0004550

Hmmmm.... I got it to crash once on a different jpg file but then could not reproduce so there must be a definitive step required that I did not do the second time. Still testing.
PhyllisSmith

PhyllisSmith

2021-01-19 16:37

manager   ~0004549

@Andrew-R
About: "I wonder if anyone ELSE getting this crash, and if so - can my hack be accepted in absence of real solution ....."

It did not crash for me on my first attempt. But I will try a different jpg file.
Andrew-R

Andrew-R

2021-01-19 12:29

reporter   ~0004548

So, for now I hacked filejpeg.C for returning different corlormodel.

I wonder if anyone ELSE getting this crash, and if so - can my hack be accepted in absence of real solution .....

fix_brender_direct_x11_jpeg.diff (579 bytes)
diff --git a/cinelerra-5.1/cinelerra/filejpeg.C b/cinelerra-5.1/cinelerra/filejpeg.C
index 42dd2189..010fc2c9 100644
--- a/cinelerra-5.1/cinelerra/filejpeg.C
+++ b/cinelerra-5.1/cinelerra/filejpeg.C
@@ -101,6 +101,10 @@ int FileJPEG::can_copy_from(Asset *asset, int64_t position)
 
 int FileJPEG::colormodel_supported(int colormodel)
 {
+// HACK, because otherwise we crash with background jpeg render and X11 direct
+// at least on 32-bit Slackware in BC_Xfer::xfer_yuv420p_to_bgr8888
+	if (colormodel == BC_BGR8888 )
+		return colormodel = BC_RGB888;
 	return colormodel;
 }
 
Andrew-R

Andrew-R

2021-01-19 09:29

reporter   ~0004547

so, I uncommented few lines in filejpeg.C:

diff --git a/cinelerra-5.1/cinelerra/filejpeg.C b/cinelerra-5.1/cinelerra/filejpeg.C
index 42dd2189..104a2ed5 100644
--- a/cinelerra-5.1/cinelerra/filejpeg.C
+++ b/cinelerra-5.1/cinelerra/filejpeg.C
@@ -101,12 +101,16 @@ int FileJPEG::can_copy_from(Asset *asset, int64_t position)

 int FileJPEG::colormodel_supported(int colormodel)
 {
+ printf("colormodel in filejpeg: %i \n ", colormodel);
        return colormodel;
 }


 int FileJPEG::get_best_colormodel(Asset *asset, int driver)
 {
+
+ printf("Driver in filejpeg: %i \n ", driver);
+
        switch(driver)
        {
                case PLAYBACK_X11:
@@ -286,14 +290,14 @@ int FileJPEG::read_frame(VFrame *output, VFrame *input)

        if( !decompressor )
                decompressor = mjpeg_new(asset->width, asset->height, 1);
-// printf("FileJPEG::read_frame %d %p %d %d %d %p %p %p %p %d\n", __LINE__,
-// input->get_data(), input->get_compressed_size(), output->get_w(), output->get_h(),
-// output->get_rows(), output->get_y(), output->get_u(), output->get_v(),
-// output->get_color_model());
+ printf("FileJPEG::read_frame %d %p %d %d %d %p %p %p %p %d\n", __LINE__,
+ input->get_data(), input->get_compressed_size(), output->get_w(), output->get_h(),
+ output->get_rows(), output->get_y(), output->get_u(), output->get_v(),
+ output->get_color_model());
        mjpeg_decompress((mjpeg_t*)decompressor, input->get_data(), input->get_compressed_size(), 0,
                output->get_rows(), output->get_y(), output->get_u(), output->get_v(),
                output->get_color_model(), 1);
-//printf("FileJPEG::read_frame %d\n", __LINE__);
+printf("FileJPEG::read_frame %d\n", __LINE__);
 //
        return 0;
 }
====

and this gives me .....

colormodel in filejpeg: 6
 colormodel in filejpeg: 6
 FileJPEG::read_frame 293 0xf56b8000 11844 684 388 0xd035a470 (nil) (nil) (nil) 6
** segv at 0x8864d05 in pid 16424, tid 16544
signal_entry_recoverable: got SIGPIPE my pid=16526
signal_entry_recoverable: got SIGPIPE my pid=16526
Ошибка сегментирования


so, apparently output->get_y , output->get_u and output->get_v are nil ?!!!
Andrew-R

Andrew-R

2021-01-19 07:21

reporter   ~0004546

valgrind log

Still points at BC_Xfer::xfer_yuv420p_to_bgr8888

I tried to figure out what was wrong with this autogenerated function (by python script.....) function but not successed ... :/

Function lives after compilation in

root@slax:/dev/shm/tmp/cinelerra-goodguy-20210112/cinelerra-5.1/cinelerra# grep xfer_yuv420p_to_bgr8888 ../guicast/xfer/*.C
../guicast/xfer/xfer.C: &BC_Xfer::xfer_yuv420p_to_bgr8888, &BC_Xfer::xfer_yuv420p_to_yuv420p,
../guicast/xfer/xfer_bc_yuv420p.C:void BC_Xfer::xfer_yuv420p_to_bgr8888 (unsigned y0, unsigned y1) {

I thought it was missing a in bgr8888 format, but apparently not .....

Both C files as generated here attached ......

valgrind.log (12,869 bytes)
xfer.C (65,897 bytes)
xfer_bc_yuv420p.C (10,631 bytes)
Andrew-R

Andrew-R

2021-01-19 05:47

reporter   ~0004545

dump (from user)

cinelerra_30567.dmp (149,670 bytes)

Issue History

Date Modified Username Field Change
2021-01-19 05:41 Andrew-R New Issue
2021-01-19 05:47 Andrew-R File Added: cinelerra_30567.dmp
2021-01-19 05:47 Andrew-R Note Added: 0004545
2021-01-19 07:21 Andrew-R File Added: valgrind.log
2021-01-19 07:21 Andrew-R File Added: xfer.C
2021-01-19 07:21 Andrew-R File Added: xfer_bc_yuv420p.C
2021-01-19 07:21 Andrew-R Note Added: 0004546
2021-01-19 09:29 Andrew-R Note Added: 0004547
2021-01-19 12:29 Andrew-R File Added: fix_brender_direct_x11_jpeg.diff
2021-01-19 12:29 Andrew-R Note Added: 0004548
2021-01-19 16:37 PhyllisSmith Assigned To => PhyllisSmith
2021-01-19 16:37 PhyllisSmith Status new => acknowledged
2021-01-19 16:37 PhyllisSmith Note Added: 0004549
2021-01-19 16:55 PhyllisSmith Note Added: 0004550
2021-01-19 19:20 Andrew-R Note Added: 0004552
2021-01-21 16:30 Andrea_Paz Note Added: 0004557
2021-01-21 16:38 Andrew-R Note Added: 0004558
2021-01-21 17:16 PhyllisSmith Note Added: 0004559
2021-01-22 08:31 Andrea_Paz Note Added: 0004565
2021-01-22 08:56 Andrew-R Note Added: 0004566
2021-01-22 09:01 Andrew-R Note Added: 0004567
2021-02-10 19:20 PhyllisSmith Note Added: 0004627
2021-02-11 03:09 Andrew-R Note Added: 0004628
2021-02-13 02:01 PhyllisSmith Note Added: 0004629
2021-02-13 22:44 PhyllisSmith Note Added: 0004634
2021-02-14 04:32 Andrew-R Note Added: 0004636
2021-02-19 23:22 PhyllisSmith Note Added: 0004652
2021-02-19 23:22 PhyllisSmith Note Edited: 0004652 View Revisions
2021-02-19 23:26 PhyllisSmith Note Edited: 0004652 View Revisions
2021-03-01 16:16 PhyllisSmith Status acknowledged => resolved
2021-03-01 16:16 PhyllisSmith Resolution open => fixed
2021-03-01 16:16 PhyllisSmith Note Added: 0004660
2021-03-02 17:48 PhyllisSmith Status resolved => closed
2021-03-02 17:48 PhyllisSmith Note Added: 0004661