updating from 4.18.1 to 4.18.2 causing xfwm4 to segfault

Just updating (archlinux based EndeavourOS) from 4.18.1 to 4.18.2 (xfconf) and on login to XFCE4 Desktop it lags and does not start xfwm4. rest is working fine.

Starting xfwm4 manually in terminal causing it to segfault. Downgrading xfconf to previoius version (4.18.1) removes the issue completely and xfwm4 starts as it should no lag too.

I can provide more info if needed.

I can provide more info if needed.

Yes please, extract a backtrace from the coredump: https://wiki.archlinux.org/title/Core_dump#Managing_the_core_dump_files

okay let me try this ;)

xfwm-dump backtrace-xconf-xwm

Hope it helps;)

Thanks, but it lacks too many symbols to be really useful, I think. You'd have to enable debuginfod in gdb, or at least install the debug packages for xfwm4 and xfconf. See https://wiki.archlinux.org/title/Debugging/Getting_traces#Debuginfod

there is no debug package for xfwm4 on arch.. only see xfconf one..

Ah, right, weird they haven't done that yet. Well, you can share the coredump if you like, I should be able to extract a full trace.

core.xfwm4.1004.a723aa0038514c8290921b2e0224be5b.4159.1697568092000000.zst

Let me know i can try again tomorrow.. need to work now.

I have just pushed xfwm4 4.18.0-2 so it'll have debug symbols once you upgrade. (Unfortunately it doesn't repro on my machine.)

just see also that if i downgrade xfconf start session update xfconf again and relogin it does not cause xfwm4 to segfault anymore.

added 1. Crash / Freeze 1. Regression labels

changed milestone to %4.18.3

I was able to repro with:

$ xfconf-query -c xfwm4 -rp /general/borderless_maximize
$ xfwm4 -r
Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done
Segmentation fault (core dumped)

Got the idea from the frequent mentions of the above property in the gdb.txt.gz backtrace attached to the downstream bug report.

Similarly to @killajoe findings, xfwm4 starts up fine afterwards (the borderless_maximize property appears to get created during the segfaulting xfwm4 invocation).

Thanks for the backtrace and for adding debug symbols for xfwm4 @foutrelis! This one is a bit weird, an infinite loop when sending the "property-changed" signal... Chances are I won't get through it tonight. @kelnos if you have time to look at it, otherwise I'll see tomorrow.

Yes, this is very strange, not sure how this could happen. I'll do my best to figure this out tonight.

This seems to be sufficient: the cache was not updated when a new property was created.

diff --git a/xfconf/xfconf-cache.c b/xfconf/xfconf-cache.c
index 9132815..80e061a 100644
--- a/xfconf/xfconf-cache.c
+++ b/xfconf/xfconf-cache.c
@@ -952,9 +952,7 @@ xfconf_cache_set(XfconfCache *cache,
         g_hash_table_insert(cache->pending_calls, old_item->cancellable, old_item);
 
         if(item) {
-            if (item->value != NULL) {
-                xfconf_cache_item_update(item, value);
-            }
+            xfconf_cache_item_update(item, value);
         } else {
             item = xfconf_cache_item_new(value, FALSE);
             g_tree_insert(cache->properties, g_strdup(property), item);

Hm, I guess I don't really understand... what is there to update if the property is still NULL?

Ohhh, nevermind. That's if the cached value is NULL, not if the new value is NULL.

Ok created !35 (merged) with a reproducer.

mentioned in merge request !35 (merged)

assigned to @Tamaranch

closed with commit 03f7ff96

Ok it's fixed by !35 (merged). Now that we're there, I think we can wait a while before releasing 4.18.3, to see if other bugs come up.

This definitely deserves a release, but on the other hand I'm not sure there are many cases other than xfwm4 where the problem can occur, and the crash only happens once, as long as the properties aren't reset (any or only some, not sure about that, it depends on what xfwm4 does).

mentioned in commit 58772649