I upgraded a second system in this house (amd32) and XFCE4 didn't want to start anymore. I get xterm, but when I want to start xfce-session X breaks. This also happened when I tried to start "The Gimp" so I guess it is inside GTK+. I'll try to downgrade back to 1.3 and see if things get into better shape. The same upgrade on my amd64 system went smoothly. Reproducible: Always Steps to Reproduce: 1. upgraded to x.org 1.4 2. startx (xfce-session) 3. crash Actual Results: Could not init font path element /usr/share/fonts/OTF, removing from list! Backtrace: 0: X(xf86SigHandler+0x82) [0x80c85a2] Fatal server error: Caught signal 4. Server aborting xinit: connection to X server lost. Couldnt get a file descriptor referring to the console Built by root@geshtinanna on 2007-09-14T19:19:12+0200 CXX: i686-pc-linux-gnu-g++ 4.1.2 (Gentoo 4.1.2) CXXFLAGS: -O2 -march=athlon-tbird -pipe -fomit-frame-pointer LDFLAGS: DATADIR: /usr/share LIBDIR: /usr/lib LIBEXECDIR: /usr/libexec SYSCONFDIR: /etc stdlib: GNU libstdc++ 20070214 libebt: 1.3.0 libwrapiter: 1.0.0 sandbox: enabled Repository virtuals: Configuration information: format: virtuals Repository installed_virtuals: Configuration information: format: installed_virtuals Repository gentoo: Configuration information: buildroot: /var/tmp/paludis cache: /usr/portage/metadata/cache distdir: /usr/portage/distfiles eclassdirs: /usr/portage/eclass format: ebuild location: /usr/portage names_cache: /usr/portage/.cache/names newsdir: /usr/portage/metadata/news pkgdir: /usr/portage/packages profiles: /usr/portage/profiles/default-linux/x86/2006.1/desktop securitydir: /usr/portage/metadata/glsa setsdir: /usr/portage/sets sync: rsync://10.0.0.205/gentoo-portage sync_options: write_cache: /var/cache/paludis/metadata Package information: app-admin/eselect-compiler: (none) app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.3.6, 2.4.4-r4, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: (none) dev-util/confcache: (none) sys-apps/baselayout: 1.12.10-r4 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 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.18 sys-devel/gcc-config: 1.4.0-r2 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 Variable information: ACCEPT_KEYWORDS: CBUILD: i686-pc-linux-gnu CFLAGS: -O2 -march=athlon-tbird -pipe -fomit-frame-pointer CHOST: i686-pc-linux-gnu CONFIG_PROTECT: CONFIG_PROTECT_MASK: CTARGET: CXXFLAGS: -O2 -march=athlon-tbird -pipe -fomit-frame-pointer DISTDIR: /usr/portage/distfiles FEATURES: GENTOO_MIRRORS: INSTALL_MASK: LANG: LC_ALL: LDFLAGS: LINGUAS: MAKEOPTS: -j2 PORTAGE_COMPRESS: PORTAGE_COMPRESS_FLAGS: PORTAGE_RSYNC_EXTRA_OPTS: PORTAGE_RSYNC_OPTS: PORTAGE_TMPDIR: /var/tmp/paludis PORTDIR: /usr/portage PORTDIR_OVERLAY: SYNC: USE: Repository installed: Configuration information: buildroot: /var/tmp/paludis format: vdb location: /var/db/pkg names_cache: /var/db/pkg/.cache/names provides_cache: /var/db/pkg/.cache/provides root: / world: /var/db/pkg/world Repository myown: Configuration information: buildroot: /var/tmp/paludis cache: /var/empty distdir: /tmp/distfiles eclassdirs: /usr/portage/eclass format: ebuild location: /usr/local/portage names_cache: /usr/local/portage/.cache/names newsdir: /usr/local/portage/metadata/news pkgdir: /usr/local/portage/packages profiles: /usr/portage/profiles/default-linux/x86/2006.1/desktop securitydir: /usr/local/portage/metadata/glsa setsdir: /usr/local/portage/sets sync: sync_options: write_cache: /var/cache/paludis/metadata
I downgrading to 1.3 had the same issues, so I'm back to 1.2 which works.
Can you set a ulimit and get a core dump, then run it through gdb and get a backtrace ??
Actually, given you have a tbird. I really suspect you have the same bug as 192048 as you are hitting a SIGILL.
(In reply to comment #2) > Can you set a ulimit and get a core dump, then run it through gdb and get a > backtrace ?? If you can give a short explanation what I should do, and what I should run through gdb, I'm happy to try. (I guess it is not as simple as 'gdb startx')
Like bug #192048, this bug should now be fixed with newer GCC, pixman and xorg-server. If this is not the case, please don't hesitate to reopen this bug. Thanks
