Liferea 1.2.13, recently upgraded, spins taking 100% of one core while printing continuously the following message on console: (Gecko:32552): GThread-CRITICAL **: g_cond_timed_wait_posix_impl: assertion `end_time.tv_nsec < G_NSEC_PER_SEC' failed Reproducible: Always Steps to Reproduce: 1. Start liferea on console 2. Wait a bit until CPU spins 3. Look at the console Actual Results: as described Expected Results: no assertions on console, no 100% cores... $ emerge --info Portage 2.1.2.2 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.21-gentoo x86_64) ================================================================= System uname: 2.6.21-gentoo x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 10 May 2007 05:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 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.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe -ftree-vectorize -ftree-vectorizer-verbose=1" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=nocona -O2 -pipe -ftree-vectorize -ftree-vectorizer-verbose=1" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="es_ES.UTF-8" LINGUAS="es es_ES en" MAKEOPTS="" 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 /usr/local/layman/voip" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acl acpi aiglx alsa amd64 apache2 arts avahi avi bash-completion berkdb bitmap-fonts bluetooth bonjour cairo cdr cli cracklib crypt cups curl dbus dlloader dri dvd dvdr dvdread eds emboss encode esd evdev evo fam firefox fortran galago gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv icu iproute2 ipv6 isdnlog java jpeg kde kdehiddenvisibility kerberos lcms ldap libg++ logrotate lucene mad midi mikmod mmx mono mouse mp3 mpeg ncurses nls nptl nptlonly nsplugin obex ogg opengl oss pam pcre pdf pdflib perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode v4l v4l2 vorbis xinerama xml xorg xrandr xv xvid zlib" ALSA_CARDS="hda-intel" 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" DVB_CARDS="usb-wt220u" ELIBC="glibc" INPUT_DEVICES="synaptics mouse evdev keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES en" USERLAND="GNU" VIDEO_CARDS="vesa i810 intel" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I know. I get this too. Here's what upstream had to say about it: This is a known problem. It only happens when using Gecko for rendering and it doesn't happen with every Gecko version. I currently cannot reproduce it, but had the same problem some months ago and even a while before. The problem is that I do not how to realize safe GDK thread locking with Gecko which does not support the GDK locking style, at least until now I found no way to use it without dead locking right after startup. And without correct locking I assume it is just a timing propability that the program locks up. Won't fix, as I have no clue how. This is so bad that I'm considering stopping using liferea.
The extra problem here is that I can't use gtkhtml, even if the build does not show the USE flag in parenthesis, inside it: !amd64? ( !xulrunner? ( !firefox? ( !seamonkey? ( =gnome-extra/gtkhtml-2* ) ) ) ) !amd64? ( gtkhtml? ( =gnome-extra/gtkhtml-2* ) ) so amd64 can't try gtkhtml :(
Nope. gtkhtml isn't supported (and often crashes) on amd64. Sorry. You can try firefox or seamonkey; I've only seen the problem on the newest xulrunner.
I've tracked this down to a 2.6.21 kernel bug on core2duos, possibly on the T7200 (since all known instances of this bug are on T7200's) The best solution at this point is to downgrade to 2.6.20, since this will undoubtedly cause other problems than liferea hanging. I will commit a workaround to liferea tomorrow, however, if it survives the night intact.
I'm changing this to the correct kernel bug, and assigning to kernel, so it can block 2.6.21 going stable on amd64 until the upstream patch goes in.
Please post the following from the system this is happening on: * dmesg * lspci * lsmod * kernel config Thanks
wouldn't it make sense to push the micropatch: --- arch/x86_64/kernel/vsyscall.c +++ arch/x86_64/kernel/vsyscall.c @@ -132,7 +132,7 @@ static __always_inline void do_vgettimeo /* convert to usecs and add to timespec: */ tv->tv_usec += nsec_delta / NSEC_PER_USEC; - while (tv->tv_usec > USEC_PER_SEC) { + while (tv->tv_usec >= USEC_PER_SEC) { tv->tv_sec += 1; tv->tv_usec -= USEC_PER_SEC; } in http://bugzilla.kernel.org/show_bug.cgi?id=8479 , or the full patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=arch/x86_64/kernel/vsyscall.c;h=dc32cef961950915fbaa185e36ab802d5f7cea3b;hp=ba330f87067996a17495f7d03466d646c718b52c;hb=c8118c6c07f2edfd697aaa0b93e08c3b65a5a675;hpb=272a3713bb9e302e0455c894c41180a482d2c8a3 into 2.6.21 patchset for amd64? Just FYI
Indeed, will do that. Thanks.
Fixed in gentoo-sources-2.6.21-r1 (genpatches-2.6.21-2)
FYI, it is already patches in gentoo-sources-2.6.21-r1
