! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfwm4 segmentation fault
Status:
RESOLVED: FIXED

Comments

Description Marlon Cabrera 2005-02-26 20:51:31 CET
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 
Comment 1 Olivier Fourdan editbugs 2005-02-28 13:37:47 CET
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.
Comment 2 Olivier Fourdan editbugs 2005-02-28 14:03:28 CET
Also, are you using the gtkqt engine (as it's listed in the packages installed)?
If so, please try with another engine.
Comment 3 Olivier Fourdan editbugs 2005-02-28 14:24:43 CET
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
------------------------------------------------------------------------------
Comment 4 Marlon Cabrera 2005-02-28 22:51:50 CET
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.


Comment 5 Marlon Cabrera 2005-02-28 23:58:18 CET
GTK-Qt 0.6 do not resolve...
Comment 6 Olivier Fourdan editbugs 2005-03-01 11:47:48 CET
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)?
Comment 7 Olivier Fourdan editbugs 2005-03-01 11:49:15 CET
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
Comment 8 Marlon Cabrera 2005-03-01 15:46:45 CET
There is no core file. :(
Comment 9 Olivier Fourdan editbugs 2005-03-01 20:00:18 CET
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?
Comment 10 Marlon Cabrera 2005-03-01 22:27:22 CET
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.
Comment 11 Olivier Fourdan editbugs 2005-03-02 06:48:19 CET
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
Comment 12 Olivier Fourdan editbugs 2005-03-05 12:48:03 CET
Sorry to bother you, but could you try what was suggested? I need a bit more
information ("xfwm4 crashes" doesn't help much).
Comment 13 Marlon Cabrera 2005-03-06 15:15:34 CET
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
 
Comment 14 Olivier Fourdan editbugs 2005-03-06 16:29:41 CET
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.

Comment 15 Olivier Fourdan editbugs 2005-03-07 21:28:59 CET
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.
Comment 16 Marlon Cabrera 2005-03-08 00:16:05 CET
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
Comment 17 Olivier Fourdan editbugs 2005-03-08 07:15:58 CET
Ohhh, that's interesting, it means that the wm crashes when run from session
manager - Benny, any idea what could be wrong?
Comment 18 Marlon Cabrera 2005-03-08 10:46:43 CET
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
Comment 19 Benedikt Meurer editbugs 2005-03-08 10:56:03 CET
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.
Comment 20 Benedikt Meurer editbugs 2005-03-08 10:57:06 CET
(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
Comment 21 Marlon Cabrera 2005-03-08 22:01:06 CET
(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






Comment 22 Marlon Cabrera 2005-03-08 23:03:59 CET
(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





Comment 23 Benedikt Meurer editbugs 2005-03-08 23:08:08 CET
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?
Comment 24 Marlon Cabrera 2005-03-09 03:08:15 CET
(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.

Comment 25 Olivier Fourdan editbugs 2005-03-09 11:40:29 CET
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.
Comment 26 Benedikt Meurer editbugs 2005-03-09 11:51:52 CET
Hm, no, thats --disable-asserts.
Comment 27 Marlon Cabrera 2005-03-09 23:24:07 CET
(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

Comment 28 Olivier Fourdan editbugs 2005-03-11 20:18:39 CET
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.
Comment 29 Olivier Fourdan editbugs 2005-09-06 12:07:13 CEST
Any update, anything new? Noone seems to be able to reproduce that.
Comment 30 Marlon Cabrera 2005-09-06 15:28:17 CEST
(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
Comment 31 Harold Aling 2007-02-15 21:20:54 CET
(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

Bug #814

Reported by:
Marlon Cabrera
Reported on: 2005-02-26
Last modified on: 2009-07-14

People

Assignee:
Olivier Fourdan
CC List:
1 user

Version

Attachments

Additional information