I built xfce4.2.0 rpm packages for Yoper distro, but xfwm4 dont start on login and when a run xfwm4 from a terminal, it clashes when a new application is started. Follow the gtk enviroment on my michine: pygtk-2.3.96-1 gtk-doc-1.2-1 gtk2-2.4.10-2 gtk+-1.2.10-4 gtkqtengine-0.5-2 gtk-xfce-engine-2.2.5-1 Reproducible: Always Steps to Reproduce: 1. xfwm4 & 2. firefox & Actual Results: I got segmentation fault for xfwm4 xfwm4.spec Summary: xfwm4 is a window manager compatable with GNOME, GNOME2, KDE2, KDE3 and Xfce Name: xfwm4 Version: 4.2.0 Release: 1 Copyright: GPL Group: GraphiX Source0: %{name}-%{version}.tar.gz #Patch0: URL: http://www.yoper.com Distribution: Yoper #Icon: yoperlogo.xpm Vendor: Yoper Limited Packager: marlon@mrgnetwork.com.br #Provides: #Requires: #AutoReqProv: no BuildRoot: %{_tmppath}/%{name}-buildroot BuildRequires: bash, binutils, gcc, glibc, ncurses, make, tar, zlib, glibc, pkgconfig, gtk+, libxml2, dbh %define _unpackaged_files_terminate_build 1 %define _missing_doc_files_terminate_build 1 %define _smp_mflags -j8 %define _target_platform i686-pc-linux-gnu %description xfwm4 is a window manager compatable with GNOME, GNOME2, KDE2, KDE3 and Xfce. %description -l pt_BR O xfwm4
Can you please provide a backtrace, because it would be pretty obvious that we wount not ship xfwm4 if such a bug was reproducible... TIA Olivier.
Also, are you using the gtkqt engine (as it's listed in the packages installed)? If so, please try with another engine.
From GTK-Qt engine website (http://www.freedesktop.org/Software/gtk-qt) ------------------------------------------------------------------------------ Changelogs Changes in 0.6: [...] * Fix crashes in XFCE, Eclipse, Azureus, Synaptic, and SciTE ------------------------------------------------------------------------------
I cant copy and paste a backtrace because the session freeze. The sequence is: ~$ gdb xfwm4 (gdb) handle SIGPIPE nostop (gdb) run (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1362)] Detaching after fork from child process 1365. Detaching after fork from child process 1366. At this point I try run another application, ex: firefox Program received signal blank_space, blank_space . [Switching to Thread 16384 (LWP 1362)] blank_space in blank_space () (gdb) At this point the session frezze, I have to do a CRTL+ALT+BACKSPACE to exit.
GTK-Qt 0.6 do not resolve...
Well, the backtrace is useless. Anyway, I'm not surprised GTK-Qt 0.6 doesn't help, the point is what if you don't use GTK-QT at all as the GTK theme (ie switch to the default GTK theme for example)?
BTW if you really want to get the backtrace, do a post mortem analysis, ie once you have the core file: gdb /usr/bin/xfwm4 -c core (gdb) bt
There is no core file. :(
If there is a crash, there is a core file unless you set ulimit -c to 0 or a value lower than the actual size of the core file (man ulimit for more information) Also, can you try by using another GTK theme as said previously?
I set ulimit -c to 2048, but no core is produced, the session just freeze. And I try to use another GTK theme, but doesnt work.
I'm sorry, but 2048 is not enough. 1) ulmmit -c unlimited 2) xfwm4 3) crash 4) gdb /usr/bin/xfwm4 -c core (gdb) bt What you could also do is run all this from a console, setting DISPLAY properly. e.g. 1) Run X from a console, "xinit /usr/X11R6/bin/xterm &" 2) Switch to a console (Ctrl+Alt+F1) 3) Set the display "export DISPLAY=:0.0" 4) run "gdb /usr/bin/xfwm4" 5) follow the usual gdb session
Sorry to bother you, but could you try what was suggested? I need a bit more information ("xfwm4 crashes" doesn't help much).
Sorry for delay.... Well, on Yoper 2.1.0 (XFree86-4.4) stable I dont have a decent backtrace, follow enviroment: gtk-doc-1.2-1 gtk2-2.4.10-2 gtk+-1.2.10-4 gtkqtengine-0.5-2 gtk-xfce-engine-2.2.5-1 gdk-pixbuf-0.22.0-8.0.1 glib-1.2.10-2 glibc-2.3.3-3 taglib-1.3-1 glib2-2.4.6-2 XFree86-4.4.0-9 But in Yoper 2.2 devel (xorg-x11-6.8.1), I got a backtrace, follow enviroment: gtk+-1.2.10-6 gtkqtengine-0.5-4 gtk-xfce-engine-2.2.5-1 gtk2-2.4.14-1 gtk-doc-1.2-5 gdk-pixbuf-0.22.0-8.0.2 xorg-x11-6.8.1-20 glibc-2.3.4-5 glib-1.2.10-4 glib2-2.4.8-1 taglib-1.3.1-1 Here is the steps to get a backtrace: ~$ ulimit -c unlimited ~$ gdb /usr/bin/xfwm4 (gdb) handle SIGPIPE nostop (gdb) run Starting program: /usr/bin/xfwm4 [Thread debugging using libthread_db enabled] [New Thread -1216731472 (LWP 3348)] Detaching after fork from child process 3351. Detaching after fork from child process 3352. --Here I run xffwm-- Program Received signal SIGSEGV segmentation fault [switching to thread -1216731472 (LWP 3348)] 0xb77560c50 in ?? () (gdb) bt #0 0xb7560c50 in ?? () #1 0xb6a01760 in _XError (dpy=0x80904b0, rep=0xb7ab09a8) at XlibInt.c:2877 #2 0xb7a02a75 in _XEventsQueued (dpy=0x80904b0, mode= -1214289724) at XlibInt.c:871 #3 0xb791f68c4 in XPending (dpy=0x80904b0) at Pending.c:54 #4 0xb7c601cd in gdk_check_xpending() from /usr/lib/libgdk-x11-2.0.so.0 #5 0xb7c62bf9 in gdk_event_check () from /usr/lib/libgdk-x11-2.0-x11.so.0 #6 0xb7afeda8 in g_main_context_check () from /usr/lib/ligglib-2.0.so.0 #7 0xb7b00f6e in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #8 0xb7b0126a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #9 0xb7dbfa63 in gtk_main () from /usr/lib/gtk-x11-2.0.so.0 #10 0x08065cb8 in main () (gdb) --here the seesion freeze, and I hav to do a CRTL+ALT+BACKSPACE to exit --- OBS.: Even setup ulimit -c unlimited, there is no core file, I have to copy this backtrace by hand. Regards, Marlon
I'm sorry, that backtrace still shows nothing wrong. The freeze occurs because you are debugging from an xterm that is managed by the window manager, ie once the window manager has crashed, the session is frozen. Why not performing the debug from a *text* console (as suggested) like this: 1) Make sure you are *not* running at level 5 (as root, "telinit 3") 2) Run X from a console, "xinit /usr/X11R6/bin/xterm &" 3) Switch to a console (Ctrl+Alt+F1) 4) Set the display "export DISPLAY=:0.0" 5) run "gdb /usr/bin/xfwm4" 6) from gdb, type "run" 7) switch to the graphic console (usually Alt+F7) 8) do whatever causes the crash 9) return to text with Ctrl+Alt+F1 and dot he backtrace (bt) 10) Post the result TIA Olivier.
Sorry, I don't want to scare you and I am thankful for the time you spend (especially if you reproduce the backtrace by hand :) It's just that we plan to release 4.2.1 by the end of the week and if ther eis something bad, I wouldn't like to miss it.
Unbeliavable!!! I follow your directions: 1) Make sure you are *not* running at level 5 (as root, "telinit 3") 2) Run X from a console, "xinit /usr/X11R6/bin/xterm &" 3) Switch to a console (Ctrl+Alt+F1) 4) Set the display "export DISPLAY=:0.0" 5) run "gdb /usr/bin/xfwm4" 6) from gdb, type "run" 7) switch to the graphic console (usually Alt+F7) 8) do whatever causes the crash 9) return to text with Ctrl+Alt+F1 and dot he backtrace (bt) 10) Post the result and there is no segmentation fault...!??!! I run xffwm, firefox without problems... So I substitute the default /etc/xdg/xfce4/xinitrc for this: #!/bin/bash /usr/bin/xfwm4 --daemon /usr/bin/xfce4-session And the xfce4 enviroment runs wihtout problems from kdm!! :) I will be testing another funcionalities, like xfce-goodies for this week. Thanks for help.... Abracos, Marlon
Ohhh, that's interesting, it means that the wm crashes when run from session manager - Benny, any idea what could be wrong?
Yep, some parameter in default xinitrc file shipped with xfce4-utils-4.2.0.tar.gz, makes the xfwm4 crashes. I dont find wich one yet. Regards, Marlon
Hm, the way xfce4-session starts applications is pretty much a g_spawn_async() call; its in libxfsm/xfsm-util.c:81. I doubt that this would cause problems for xfwm4. If its really a problem with xfce4-session/xfwm4, then I'd guess its a problem with the splash screen or something like that. But Yoper rings a bell here: IIRC Yoper used some CFLAGS that are known to trigger code generation bugs in gcc. Marlon, please post the settings of your CFLAGS and CPPFLAGS to make sure we are really hunting a bug in Xfce here.
(In reply to comment #18) > Yep, some parameter in default xinitrc file shipped with > xfce4-utils-4.2.0.tar.gz, makes the xfwm4 crashes. > I dont find wich one yet. That means it works if you run xfce4-session instead of startxfce4, right? Benedikt
(In reply to comment #20) > That means it works if you run xfce4-session instead of startxfce4, right? Huumm, to work I had to replace the original /etc/xdg/xfce4/xinitrc with this one: #!/bin/bash /usr/bin/xfwm4 --daemon /usr/bin/xfce4-session On Yoper kdm run /usr/bin/startxcfe4 , what execute the /etc/xdg/xfce4/xinitrc
(In reply to comment #19) > > Marlon, please post the settings of your CFLAGS and CPPFLAGS to make sure we are > really hunting a bug in Xfce here. CFLAGS="-march=i686 -O3 -pipe -mcpu=i686" CXXFLAGS="${CFLAGS}" root@arwen ~ # gcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.1/specs Configured with: ../gcc-3.4.1/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,f77,objc --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu Thread model: posix gcc version 3.4.1 Abracos, Marlon
Hm, -O3 is not recommended, tho it *should* not break on ia32. For the xinitrc you posted: Does it work if you remove the xfwm4 line from the file?
(In reply to comment #23) > Hm, -O3 is not recommended, tho it *should* not break on ia32. > > For the xinitrc you posted: Does it work if you remove the xfwm4 line from the file? No, xfwm4 dont starts.
Benny, just a thought, could the "--disable-debug" flag used in the spec file to generate the binary have any effect such as disabling the g_return_if_fail() or g_return_val_if_fail() checks, or something like that? Olivier.
Hm, no, thats --disable-asserts.
(In reply to comment #23) > Hm, -O3 is not recommended, tho it *should* not break on ia32. oops, this is the correct FLAGS for yoper: CFLAGS='-O2 -g -march=i686 -mtune=i686' CXXFLAGS='-O2 -g -march=i686 -mtune=i686' FFLAGS='-O2 -g -march=i686 -mtune=i686' Marlon
I'm trying to guess what the problem could be and, from the scenario, I'd like to see your xfwm4 session files. Can you tar and post the content of ~/.xfce4/sessions/ and ~/.config/xfce4/xfwm4/sessions/ and post it directly to me (fourdan@xfce.org) Once done, can you try to remove the files fro mtese directories and retry with the default startup script (ie try to remove the launch of xfwm4 prior to running xfce4-session) TIA Olivier.
Any update, anything new? Noone seems to be able to reproduce that.
(In reply to comment #29) > Any update, anything new? Noone seems to be able to reproduce that. No. To xfce4 work properly on Yoper I had to replace the original /etc/xdg/xfce4/xinitrc with this one: #!/bin/bash /usr/bin/xfwm4 --daemon /usr/bin/xfce4-session I will try upgrade to xfce 4.2.2. abra
(In reply to comment #30) > (In reply to comment #29) > > Any update, anything new? Noone seems to be able to reproduce that. > > No. To xfce4 work properly on Yoper I had to replace the original > /etc/xdg/xfce4/xinitrc with this one: > > #!/bin/bash > > /usr/bin/xfwm4 --daemon > /usr/bin/xfce4-session > > I will try upgrade to xfce 4.2.2. > > abra�os, > > Marlon > Never heard from him again... Assuming it's fixed in 4.4