View Issue Details

IDProjectCategoryView StatusLast Update
0000587Cinelerra-GG[All Projects] Bugpublic2021-09-19 02:49
ReporterAndrew-R Assigned ToPhyllisSmith  
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000587: Cin crash in qemu on non-ssse3 cpu
DescriptionI was trying to make 'universal' build of CinGG for using (playing with and showing off) on old Celeron 1Ghz (only mmx and sse, not quite vintage tho). I build it under mixed Slackware 14.1/14.2 environment (glibc/gcc from 14.2, rest from 14.1) and made this ISO:
760 MB
sha256sum CDROM-4.14.246-big-7.iso
f8693dfb7ca93c8fe8826c4e95a743de69eef71fa2f66634450ea30fbc6413ba CDROM-4.14.246-big-7.iso

You hopefully can boot it on qemu (I use 5.1) like this:
 qemu-system-i386 -display sdl,gl=on -soundhw es1370 -cdrom /mnt/sdb1/admin/CDROM-4.14.246-big-7.iso -enable-kvm -m 512 -smp 4 -cpu core2duo (you can boot without -smp , so single core, and give it more memory if you want)
Steps To ReproduceNow, this Slackware (Slax) cd will boot under qemu into text mode.

Log in as guest/guest (or root/toor), issue 'startx'

You should see kde3, from there you can alt-f2 -> cin or find it in menu under Multimedia.

Try to download file from called
 Space_Cowboys.avi 2005-12-09 03:24 3.4M

links should work

Try to load said file into CinGG.

with core2duo it will work (check /proc/cpuinfo to see ssse3)

with older coreduo it will crash on load :(

I tried to re-compile latest source release under this live environment (a bit tight, but by removing tarballs and unwanted bins it compiles and setting some Ofast flags to O2 instead, but there still was crash :(

I suspect this is alignment issue, masked by glibc (?) making use of ssse3.

I tried my bigger iso (dvd-sized) and self-compiled CinGG there also crashes with non-ssse3 cpu in qemu (and works if I set -cpu to 'host')

This might be qemu bug, so testing on pre-ssse3 real cpu will be helpful
TagsNo tags attached.




2021-09-19 02:49

reporter   ~0004972

this is exactly my problem - I do not understand why I suddently got this result! May be one thread feed uninitialized value down to this function? or some weird asm-level interaction...


2021-09-19 01:27

manager   ~0004971

This is too hard for me, but it is so strange that hscale is 1.000000 before and after the -nan (not a number, but we know it is negative!). If it is going outside the address space (address sanitizer), how can it come back so easily?


2021-09-17 00:51

reporter   ~0004968

checking for nan for hscale eliminates crash, but then processing (for example via fade automation) completely broken :/

cat cdrom_root/tmp/guicast-2.diff
diff --git a/cinelerra-5.1/guicast/bcxfer.C b/cinelerra-5.1/guicast/bcxfer.C
index 8eb6533b..da437114 100644
--- a/cinelerra-5.1/guicast/bcxfer.C
+++ b/cinelerra-5.1/guicast/bcxfer.C
@@ -1,3 +1,4 @@
+#include <cmath>

 void BC_Xfer::init(
        uint8_t **output_rows, int out_colormodel, int out_x, int out_y, int out_w, int out_h,
@@ -101,11 +102,19 @@ void BC_Xfer::init(
        this->total_out_w = out_rowspan;
        this->in_pixelsize = BC_CModels::calculate_pixelsize(in_colormodel);
        this->out_pixelsize = BC_CModels::calculate_pixelsize(out_colormodel);
        if( in_w ) {
                this->scale = (out_w != in_w) || (in_x != 0);
 /* + 1 so we don't overflow when calculating in advance */
                column_table = new int[out_w+1];
                double hscale = (double)in_w/out_w;
+ if (isnan(hscale))
+ hscale = (double)in_w/out_w;
+ //printf("hscale = %f \n", hscale);
+ //printf("in_w: %i \n", in_w);
+ //printf("out_w: %i \n", out_w);
+ //printf("in_x: %i \n", in_x);
                for( int i=0; i<out_w; ++i ) {
                        column_table[i] = ((int)(hscale * i) + in_x) * in_pixelsize;
                        if( in_colormodel == BC_YUV422 || in_colormodel == BC_UVY422 )
diff --git a/cinelerra-5.1/guicast/xfer/Makefile b/cinelerra-5.1/guicast/xfer/Makefile
index ff12aa48..39557ac7 100644
--- a/cinelerra-5.1/guicast/xfer/Makefile
+++ b/cinelerra-5.1/guicast/xfer/Makefile
@@ -11,7 +11,7 @@ all: $(OUTPUT)
        rm -rf $(OBJDIR) xfer*.[Ch]

+BFLAGS:=-O0 -g -fsanitize=address -fsanitize=undefined

 $(OBJDIR)/%.o: %.C
        $(CXX) -I.. `cat $(OBJDIR)/c_flags` $(BFLAGS) -DMSGQUAL=$* -c $< -o [email protected]
[email protected]:/mnt/sdb1/admin#


2021-09-16 23:01

reporter   ~0004967

so I added debug like this

cat cdrom_root/tmp/guicast.diff
diff --git a/cinelerra-5.1/guicast/bcxfer.C b/cinelerra-5.1/guicast/bcxfer.C
index 8eb6533b..d0a8aafe 100644
--- a/cinelerra-5.1/guicast/bcxfer.C
+++ b/cinelerra-5.1/guicast/bcxfer.C
@@ -106,8 +106,12 @@ void BC_Xfer::init(
 /* + 1 so we don't overflow when calculating in advance */
                column_table = new int[out_w+1];
                double hscale = (double)in_w/out_w;
+ printf("hscale = %f \n", hscale);
+ printf("in_w: %i \n", in_w);
+ printf("out_w: %i \n", out_w);
+ printf("in_x: %i \n", in_x);
                for( int i=0; i<out_w; ++i ) {
- column_table[i] = ((int)(hscale * i) + in_x) * in_pixelsize;
+ column_table[i] = (int)(((hscale * i) + in_x) * in_pixelsize);
                        if( in_colormodel == BC_YUV422 || in_colormodel == BC_UVY422 )
                                column_table[i] &= 0000003:0000003;
diff --git a/cinelerra-5.1/guicast/xfer/Makefile b/cinelerra-5.1/guicast/xfer/Makefile
index ff12aa48..efb2e628 100644
--- a/cinelerra-5.1/guicast/xfer/Makefile
+++ b/cinelerra-5.1/guicast/xfer/Makefile
@@ -11,7 +11,7 @@ all: $(OUTPUT)
        rm -rf $(OBJDIR) xfer*.[Ch]

+BFLAGS:=-Ofast -fsanitize=address -fsanitize=undefined

 $(OBJDIR)/%.o: %.C
        $(CXX) -I.. `cat $(OBJDIR)/c_flags` $(BFLAGS) -DMSGQUAL=$* -c $< -o [email protected]

and this resulted in debug output file like this ..strangely, at one time before crash hscale was '-nan' ?!

cin_debug_log.log (157,793 bytes)


2021-09-16 21:57

reporter   ~0004966

so if I change line 110 in;a=blob;f=cinelerra-5.1/guicast/bcxfer.C;h=8eb6533baa68b7cc8b3fe1d763f03d65a3d28b4e;hb=HEAD

column_table[i] = ((int)(hscale * i) + in_x) * in_pixelsize;
column_table[i] = ((long long)(hscale * i) + in_x) * in_pixelsize;

it stopped crashing, yet miniatures on timeline are garbage :(


2021-09-16 21:22

reporter   ~0004965

So, I compiled Cin with address sanitizer and result was:

cat cin_addr_sanitizer.log
Cinelerra Infinity - built: Sep 16 2021 21:38:07
(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.

init plugin index: /usr/lib/cin/plugins
init lv2 index: /usr/share/cin/lv2
init ladspa index: /usr/lib/cin/ladspa
../bcxfer.C:110:49: runtime error: signed integer overflow: -2147483648 * 3 cannot be represented in type 'int'
==2556==ERROR: AddressSanitizer: SEGV on unknown address 0x26427e00 (pc 0x08a18b4e bp 0xa8efd728 sp 0xa8efd6d0 T71)
    #0 0x8a18b4d in BC_Xfer::xfer_rgb888_to_bgr8888(unsigned int, unsigned int) (/usr/bin/cin+0x8a18b4d)
    0000001 0x88e47fa in BC_Xfer::xfer_slices(int) (/usr/bin/cin+0x88e47fa)
    0000002 0x88e725d 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) (/usr/bin/cin+0x88e725d)
    0000003 0x882b788 in BC_Bitmap::read_frame(VFrame*, int, int, int, int, int, int, int, int, int) (/usr/bin/cin+0x882b788)
    #4 0x88add6d in BC_WindowBase::draw_vframe(VFrame*, int, int, int, int, int, int, int, int, BC_Pixmap*) (/usr/bin/cin+0x88add6d)
    0000005 0x885fd33 in BC_Pixmap::draw_vframe(VFrame*, int, int, int, int, int, int) (/usr/bin/cin+0x885fd33)
    0000006 0x84ab6f0 in AssetPicon::create_objects() (/usr/bin/cin+0x84ab6f0)
    0000007 0x84afaf1 in AWindowGUI::update_asset_list() (/usr/bin/cin+0x84afaf1)
    0000008 0x84b00b5 in AWindowGUI::update_assets() (/usr/bin/cin+0x84b00b5)
    #9 0x84b0417 in AWindowGUI::receive_custom_xatoms(XClientMessageEvent*) (/usr/bin/cin+0x84b0417)
    0000010 0x88a5c39 in BC_WindowBase::dispatch_event() (/usr/bin/cin+0x88a5c39)
    0000011 0x88a63c7 in BC_WindowBase::run_window() (/usr/bin/cin+0x88a63c7)
    #12 0x84b2544 in AWindow::run() (/usr/bin/cin+0x84b2544)
    #13 0x88bd22e in Thread::entrypoint(void*) (/usr/bin/cin+0x88bd22e)
    0000014 0xb7a330c4 (/usr/lib/
    0000015 0xb79b5362 (/usr/lib/
    #16 0xb77ef6f1 in start_thread (/lib/
    #17 0xb684923d in __clone (/lib/

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 BC_Xfer::xfer_rgb888_to_bgr8888(unsigned int, unsigned int)
Thread T71 created by T0 here:
    #0 0xb79b5171 in pthread_create (/usr/lib/
    0000001 0x88bd51f in Thread::start() (/usr/bin/cin+0x88bd51f)
    0000002 0x86630c7 in MWindow::start() (/usr/bin/cin+0x86630c7)
    0000003 0x8349430 in main (/usr/bin/cin+0x8349430)
    #4 0xb6767696 in __libc_start_main (/lib/


this is even without loading any avi, just jpeg from /usr/share/wallpapers.


2021-09-13 16:05

reporter   ~0004959

@PhyllisSmith, you can try and install qemu (user-space part of kvm-based virtualization, but also usable as independent emulator) on Fedora fom repository?
$ su -c "dnf install qemu"

and then try line like

qemu-system-i386 -cdrom /path_to_iso/CDROM-4.14.246-big-7.iso -enable-kvm -m 512 -cpu pentium3,+ssse3

yes, I just tested, it works with this fictional cpu :} you can add '?' as parameter to '- cpu' and qemu will give you big list of possible cpus... If you omit 'enable-kvm' it will boot in pure emulation mode (even if kvm/virtualization tot enabled ...something you often need to check in BIOS setup ...) - quite slow (talk about minutes until even text login)!


2021-09-13 15:55

manager   ~0004958

I have downloaded the iso but not sure how I can even try it. Also downloaded the Space Cowboys and of course, had to play that on my laptop -- that was and still is a good movie. In looking at the dmp file, I have no clue and am not adept at reading much there -- it just looks like it crashes on the "Load" just like you stated. Although it sort of looks like it got started because the size is 3,559,424 but the position is 1,386,508 which I am only guessing means that it got to that point before crashing.


2021-09-13 14:57

reporter   ~0004957

here is 'dmp' log from VM ....

cinelerra_1571.dmp (80,675 bytes)

Issue History

Date Modified Username Field Change
2021-09-13 14:15 Andrew-R New Issue
2021-09-13 14:57 Andrew-R File Added: cinelerra_1571.dmp
2021-09-13 14:57 Andrew-R Note Added: 0004957
2021-09-13 15:55 PhyllisSmith Assigned To => PhyllisSmith
2021-09-13 15:55 PhyllisSmith Status new => acknowledged
2021-09-13 15:55 PhyllisSmith Note Added: 0004958
2021-09-13 16:05 Andrew-R Note Added: 0004959
2021-09-16 21:22 Andrew-R Note Added: 0004965
2021-09-16 21:57 Andrew-R Note Added: 0004966
2021-09-16 23:01 Andrew-R File Added: cin_debug_log.log
2021-09-16 23:01 Andrew-R Note Added: 0004967
2021-09-17 00:51 Andrew-R Note Added: 0004968
2021-09-19 01:27 PhyllisSmith Note Added: 0004971
2021-09-19 02:49 Andrew-R Note Added: 0004972