Cinelerra completely freezes after closing the Tip of the Day window. Mouse cursor still reacts to UI components, for example it changes to "text cursor" when over text input box and so on. I've tried removing the old config directory (~/.bcast/, are there any else?) but it didn't help. Reproducible: Always Steps to Reproduce: 1. run cinelerra 2. close Tip of the Day window Actual Results: Cinelerra freezes completely. Portage 2.1.2.7 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r2 x86_64) ================================================================= System uname: 2.6.21-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System release 1.12.10 Timestamp of tree: Wed, 30 May 2007 06:20:01 +0000 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer noinfo parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.public.fix.fi/gentoo/ http://trumpetti.atm.tut.fi/gentoo" LANG="fi_FI.UTF-8" LC_ALL="fi_FI.UTF-8" LINGUAS="fi" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 avahi berkdb bitmap-fonts bzip2 cairo cdparanoia cdr cli cracklib crypt dbus dga dts dvd dvdr encode exif fam ffmpeg flac fortran gdbm geoip gnome gnutls gstreamer gtk hal iconv imagemagick isdnlog jpeg lcms libg++ libnotify mad matroska midi mmx mono mpeg mudflap ncurses nls nptl nptlonly offensive ogg opengl openmp pam pcre pdf perl png pppd python readline reflection session spell spl sse sse2 ssl startup-notification svg symlink tcpd theora threads truetype truetype-fonts type1-fonts unicode usb vorbis x264 xcomposite xml xorg xprint xulrunner xv xvid zlib" ALSA_CARDS="intel8x0 ens1371" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" CAMERAS="panasonic" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fi" USERLAND="GNU" VIDEO_CARDS="none nvidia nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 120690 [details] output This is the output from terminal
Same problem here. Starting with "strace cinelerra" and disabling "Tips of the day" allows cinelerra's main GUI to respond. Sometimes it still starts with an unresponsive main GUI though. Perhaps it's a threading bug in cinelerra ?
yep, same here, and same with latest cinelerra cv version on cvs.cinelerra.org. There is that : http://bugs.cinelerra.org/show_bug.cgi?id=414 what's strange is that it used to have no problem... probably a deadlock trigerred somewhere as it seems to wait forever for pthread_join in guicast/bcclipboard.C : 64
hmmm after some more testing, I tried emerging libX11 with USE=-xcb, and cinelerra worked fine again... could you please try if that helps you aswell ?
(In reply to comment #4) > hmmm after some more testing, I tried emerging libX11 with USE=-xcb, and > cinelerra worked fine again... Yes, this fixes the problem.
then adding x11@, I'm sure you'll know better than me what to do ;) Here is my analysis : The XSendEvent at guicast/bcclipboard.C:62 seems to be never received. Uncommenting the printf at : guicast/bcclipboard.C:76 & 78 showed that XNextEvent(out_display, &event) never returned, thus the thread never finishes, thus pthread_join waits forever, thus cinelerra freezes... My libX11 knowledge is very rough, is there a bug in cinelerra or is that due to xlib/xcb ? what's weird is that it sometimes work when run under gdb, sometimes it does not. That seems to be some race conditions, but I've still not found if that's cinelerra's fault or not :/
Yeah, same with strace: it does work more often, but still happens sometimes.
It definitely sounds like a timing problem in cinelerra's threading code. Xcb introduces some new threading functionality which probably triggered the problem. I moderately doubt this is an X bug, but I wouldn't discount the possibility. The bug should probably be moved to one or both upstreams.
Same issue here as well using cinelerra-cvs-20070607 and libX11-1.1.2-r1 compiled with xcb USE flag. When libX11 is compiled w/o xcb flag, then everything works as expected.
Graaah, I can't trigger it anymore with 20070726 ebuild... the only major change I can see in thread handling is the upgrade to glibc 2.6, as there is no such change in cinelerra's code. Can anyone reproduce this with it ? I've had some headaches debugging threads here and now it just works fine.... :(
Hmm - it's still triggering for me - I recompiled libX11 and mesa with the xcb USE flag, then emerged the latest and greatest cinelerra package, and still ahve the same behaviour.
The bug is still present here with cinelerra-cvs-20080602, running on up to date x86. Recompiling libX11 with USE="-xcb" helps. The problem also disappears, when I run cinelerra as root (not that I would recommend such risky action to anyone)
> The problem also > disappears, when I run cinelerra as root (not that I would recommend such risky > action to anyone) > Same here, but how to explain this? \ I have laptop with the AMD64 X2 and PC with AMD64 "X1". Both systems are compiled with USE="xcb" (compiz installed). So, the problem is only at PC.
Not a nice fix, but here's what fixed it for me so far: I've followed http://akiradproject.net/node/25 which lead me to https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/185311/comments/159 so long story short I've done: # USE="-xcb" emerge -B =x11-libs/libX11-1.1.5 # mkdir /opt/libX11-noxcb # tar -xjf /usr/portage/packages/libX11-1.1.5.tbz2 -C /opt/libX11-noxcb # mv /opt/libX11-noxcb/usr/lib64/libX11* /opt/libX11-noxcb # mv /usr/bin/cinelerra /usr/bin/cinelerra-bin # cat > /usr/bin/cinelerra #!/bin/sh LD_LIBRARY_PATH=/opt/libX11-noxcb/:$LD_LIBRARY_PATH /usr/bin/cinelerra-bin Ctrl-D # chmod +x /usr/bin/cinelerra done. Ain't pretty, but works. will break with next update and leave ugly trace in shape of /usr/bin/cinelerra-bin, but at least I can use it right now. Maybe ebuild should reflect the above and build local version of libX11 with no xcb and bundle it with cinelerra ?
(In reply to comment #14) Here is a nicer form of the fix, gentoo-specific: # mkdir /opt/libX11-noxcb Portage users: # USE="-xcb" emerge -B =x11-libs/libX11-1.1.5 # tar -xjf /usr/portage/packages/libX11-1.1.5.tbz2 -C /opt/libX11-noxcb Paludis users: After changing to -xcb use.conf: # paludis --abort-at-phase merge -i libX11 # mv /var/tmp/paludis/x11-libs/libX11-1.1.5/image/* /opt/libX11-noxcb (Remember to switch back to xcb in use.conf) # mv /opt/libX11-noxcb/usr/lib64/libX11* /opt/libX11-noxcb # cat > /usr/local/bin/cinelerra #!/bin/sh LD_LIBRARY_PATH=/opt/libX11-noxcb/:$LD_LIBRARY_PATH /usr/bin/cinelerra Ctrl-D # chmod +x /usr/local/bin/cinelerra This way is less obtrusive.
How about depending on libX11[-xcb] instead? All those hacks look pretty gross to me. Cheers
(In reply to comment #16) > How about depending on libX11[-xcb] instead? All those hacks look pretty gross to me. The problem is that compiz and kdelibs need xcb.
Then I'm out of ideas, this is probably a bug in either xcb, libX11 or in cinelerra's threading code. There isn't much we can do here, except maybe "fix" cinelerra (threading with a GUI is *hard*). Try opening a bug in FreeDesktop's bugzilla. That's all I can think of right now. Thanks
why is bundling of separately built libX11 is out of question? I know it's ugly and not very gentoo-like, however it would provide immediate fix until something better is found.
See these related bugs: http://bugs.cinelerra.org/show_bug.cgi?id=383 http://bugs.cinelerra.org/show_bug.cgi?id=406 http://bugs.cinelerra.org/show_bug.cgi?id=414 http://bugs.cinelerra.org/show_bug.cgi?id=528
I don't get this problem but another one (cinelarra freeze after stopping the playing) here on ~amd64. # emerge -vp x11-libs/libX11 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libX11-1.1.5 USE="ipv6 -debug -xcb" 0 kB So, my USE flags for libX11 seam to confirm that the Tip of the Day freeze is related to USE=xcb. And also that the freeze after stop is another problem. I will fill another bug report. Also, I have kdelibs and the few kde programs in my system are working fine with USE=-xcb.
The Freeze after stop was caused by a bad sound config. I have jackd running all the time, use ALSA as cinelerra sound output, and a pcm jack plug into ~/.asoundrc. For this to work, it was necessary to check into cinelerra sound preferences "Verrouiller l'arret de la lecture (en cas de probleme)", something like "Look the stop of playing (in case of problem)". The good news is that it will be no other bug report. Sorry for the noise.
Try cinelerra-20100320.
(In reply to comment #23) > Try cinelerra-20100320. No reply since this request. Closing as OBSOLETE.
