xfwm4 killed with SIGTRAP from glib in clientSendConfigureNotify client.c:699 calling XSendEvent().
Summary
xfwm4 killed with SIGTRAP from glib in clientSendConfigureNotify client.c:699 calling XSendEvent().
Context
- Xubuntu 20.04, up-to-date, no heavy configuration tweaking or special software installed, no PPA (initially). Machine seems sane, no mysterious crashes.
Path followed
- xfwm4 crashes (and is automatically restarted) about once a week. (By the way, after xfwm4 restart, all windows get moved to the right and bottom by the thickness of left and top decorations in the style used.)
- I logged in on /dev/tty1 and there started gdb which ran fxwm4 --replace.
- Installed Ubuntu PPA for dbgsym packages and xfwm4-dbgsym.
- This time, crash happened after machine (a laptop) woke from suspend-to-ram. Other crash conditions exist.
- X session was reachable but could not focus any window, so I guessed xfwm4 was frozen.
- Indeed on /dev/tty1 gdb was available. Captured stack trace and core dump.
- Stack trace is attached: gdb_xfwm4_02_bt.txt
- Core dump available, just ask.
Activity
mentioned in issue thunar#327 (closed)
Compiled package from https://packages.ubuntu.com/groovy/xfwm4 to see if problem remains. I'll try to report here within, say, a month. Silence might mean problem is resolved.
As observed by brainwash on IRC #xfce-dev, it may be relevant to run xfwm4 with GDK_SYNCHRONIZE in environment variable next time I'd like to get a stack trace. From the log:
To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.
TL;DR: 3rd item "X error" below might be actionable.
Bug still happening with more recent xfwm, will try.
Since the bug still happens with package compiled on https://packages.ubuntu.com/groovy/xfwm4 I'm going to try again running it synchronously.
Intuition: common cause of other bugs?
Since running Xubuntu 20.04, I also had xfce4-terminal crash from time to time, killing all running terminals and programs still attached to them.
It might be the same common cause.
X error: already posted
@olivier Thank you for the hint:
You may as well post the actual X11 error as reported in the logs, because that alone can give some hints as to what the actual X11 error is, and therefore where it's from, originally.
Well, it's in the attached file https://gitlab.xfce.org/xfce/xfwm4/uploads/9b3ea5ed6a07d915d7dc974f5afbbfdf/gdb_xfwm4_02_bt.txt . I actually pasted more than the stack trace:
The error was 'BadWindow (invalid Window parameter)'. (Details: serial 1336329 error_code 3 request_code 12 (core protocol) minor_code 0)mentioned in commit ec3b1b12
mentioned in commit 083e6de0
mentioned in commit 659fd0dd
Hi @olivier.
Requested information
xfwm4 --version
This is xfwm4 version 4.14.2 (revision bb38fd909) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.20, using GTK+-3.24.20. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): NoAdditional information
Currently running xfwm4 from regular Ubuntu package 4.14.2-1 .
Crash still happen often. I can tell because as written earlier "after xfwm4 restart, all windows get moved to the right and bottom by the thickness of left and top decorations in the style used".
I noticed a number of lines in kernel log, of the form:
traps: xfwm4[106570] trap int3 ip:7fcbcec4d0d5 sp:7ffc90ea5c50 error:0 in libglib-2.0.so.0.6400.3[7fcbcec11000+84000]
Well, these do happen quite often after all, here is a count per full month:
48 Jul 48 Sep 70 Oct 80 NovQuestion
Should I try some version from git or anything?
Thank you for your attention.
Okay. Now running latest master:
xfwm4 --version This is xfwm4 version 4.15.3git.8c86c4eeb (revision 8c86c4eeb) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.20, using GTK+-3.24.20. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - X Input 2 support: No - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No xfwm4 --replace & [1] 87099 $ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done(As a side note, out-of-source configure failed, so I made an in-source build, but that's a different topic.)
Next step
I will tell if problem still occurs and the like.
added 1. Crash / Freeze label
@stephane.gourichon: Any update on the testing of git?
TL;DR: git master also crashes
Thanks @philipzae for asking.
version 4.15.3git.8c86c4eebalso crashes from time to time, just the same as 4.14.2 .I restarted it under valgrind, just to see.
After 4 errors at start-up, it just runs.
==602751== Command: xfwm4 --replace ==602751== Invalid write of size 8 ==602751== Conditional jump or move depends on uninitialised value(s) ==602751== Conditional jump or move depends on uninitialised value(s) ==602751== Syscall param writev(vector[...]) points to uninitialised byte(s)Any feedback welcome.
-
Thanks @stephane.gourichon.
@olivier: thoughts on how to proceed.
Okay. Now running latest master:
xfwm4 --version This is xfwm4 version 4.15.3git.8c86c4eebWell, 4.15.3 is still very old, I'm afraid
(And FWIW,
valgrindwon't help here, this is not a memory corruption, this is a XError raised by the Xserver).The initial backtrace you posted points at :
#11 0x00007ffff6ec1082 in XSendEvent () at /lib/x86_64-linux-gnu/libX11.so.6 #12 0x00005555555686ce in clientSendConfigureNotify (c=c@entry=0x5555559d75d0) at client.c:699 #13 0x0000555555568988 in clientConfigure (c=0x5555559d75d0, wc=wc@entry=0x7fffffffc4c0, mask=<optimized out>, mask@entry=3, flags=flags@entry=3) at client.c:847And that code is precisely protected by an
ErrorTrapPush()/ErrorTrapPop()so this just cannot be the culprit.X11 protocol is asynchronous, meaning that a request may raise an error from the Xserver several replies later, that's why posting a backtrace from an XError without running synchronized (
GDK_SYNCHRONIZE) is usually next to useless.So my initial advise remain, please run a current version, see if that helps - Failing that, a backtrace running synchronized would be the only way forward.
Now, sometimes (often, even?) running synchronized will avoid the issue entirely because it slows things down a lot.
This is xfwm4 version 4.15.3git.8c86c4eebWell, 4.15.3 is still very old, I'm afraidMy tags were outdated which caused git describe to attach to 4.15.3. With up-to-date tags, git describe for the same commit now says xfce-4.16pre2-134-g8c86c4ee from 2020-12-06. Anyway I no longer run it, see below.
(And FWIW,
valgrindwon't help here, this is not a memory corruption, this is a XError raised by the Xserver).I did it just in case there was some memory corruption in xfwm4 process. Not observed, and it makes sense with what you write.
X11 protocol is asynchronous, meaning that a request may raise an error from the Xserver several replies later, that's why posting a backtrace from an XError without running synchronized (
GDK_SYNCHRONIZE) is usually next to useless.Okay.
So my initial advise remain, please run a current version, see if that helps - Failing that, a backtrace running synchronized would be the only way forward.
I switched to latest master, now running xfwm4-4.16.1-62-g0af0e435
I'm going to follow what you wrote precisely: start running current version normally (no
GDK_SYNCHRONIZE).I had this once (running with
nohup bash -c 'export GDK_SYNCHRONIZE=1 ; xfwm4 --replace' &):(xfwm4:997440): xfwm4-WARNING **: 19:09:20.632: Could not find a screen to manage, exitingNow running like this:
nohup bash -c 'unset GDK_SYNCHRONIZE ; xfwm4 --replace' &I'll try to keep an eye for crash again and think to come back here. Thank your for your feedback and concrete advice.
