Created attachment 8655 screenshot Description: When opening AppFinder via keyboard shortcut for a while in a session, two or more windows start to open at the same time randomly, despite having activated the options "single windows" and "keep running instance in the background". When the start of AppFinder occurs, it becomes slow, and a generalized lag is felt in the system. When reviewing the task manager, I realize that there are several instances of xfce4-appfinder running at the same time (see screenshot) Steps to Reproduce: 1. Repeatedly open AppFinder via keyboard shortcut in the same session Actual Results: Randomly opens two or more windows of AppFinder at the same time after a slow start. When looking at the task manager, it shows how two or more open xfce4-appfinder processes are open. Expected Results: Only one single AppFinder window is opened, maintaining a single background process. Platform: Fedora Workstation 30 XFCE 64 bit xfce4-appfinder-4.13.3-1.fc30.src.rpm
On a terminal, please run xfce4-appfinder -q && xfce4-appfinder. Now try to reproduce the issue and watch for error messages.
(In reply to Andre Miranda from comment #1) > On a terminal, please run xfce4-appfinder -q && xfce4-appfinder. > Now try to reproduce the issue and watch for error messages. On this occasion the following error was shown. Curiously, many windows were opened at the same time. [rsvg_internals/src/svg.rs:84] &self.load_options.base_url = None (xfce4-appfinder:14642): GLib-GObject-WARNING **: 03:23:12.649: invalid uninstantiatable type '-g-type-private--GTypeFlags' in cast to 'GarconMenuItemAction' (xfce4-appfinder:14642): garcon-CRITICAL **: 03:23:12.649: garcon_menu_item_action_get_name: assertion 'GARCON_IS_MENU_ITEM_ACTION (action)' failed (xfce4-appfinder:14642): GLib-GObject-WARNING **: 03:23:12.649: invalid uninstantiatable type '-g-type-private--GTypeFlags' in cast to 'GarconMenuItemAction' (xfce4-appfinder:14642): garcon-CRITICAL **: 03:23:12.649: garcon_menu_item_action_get_name: assertion 'GARCON_IS_MENU_ITEM_ACTION (action)' failed Segmentation fault (`core' generado)
Created attachment 8656 No errors shown Making common use of the system, I noticed that sometimes the terminal does not show any error, such as the screen capture, despite the fact that two windows were opened at the same time.
The first error looks like appfinder crashed because of garcon, which version of it do you have installed? If not already 0.6.2 please try to update. The errors from screenshot look like to stem from applications launched by appfinder, so probably not related to this bug. For single instance appfinder relies on dbus, you can use D-Feet to check if an instance is running and what's its PID. Unfortunately it's hard to tell what's wrong here without reproducing the problem which may be caused but some configuration or it's dependent of package versions provided by your distribution. Is it possible to reproduce this on fresh install (virtual machine) of Fedora 30?
(In reply to Andre Miranda from comment #4) > The first error looks like appfinder crashed because of garcon, which > version of it do you have installed? If not already 0.6.2 please try to > update. I have version 0.6.2 > The errors from screenshot look like to stem from applications launched by > appfinder, so probably not related to this bug. Yes I know, my point here was to show that when the problem occurs, no output of the "bug" is displayed. I tried to replicate it many times, but never shows an output in the terminal. > For single instance appfinder relies on dbus, you can use D-Feet to check if > an instance is running and what's its PID. Unfortunately it's hard to tell > what's wrong here without reproducing the problem which may be caused but > some configuration or it's dependent of package versions provided by your > distribution. Is it possible to reproduce this on fresh install (virtual > machine) of Fedora 30? Ok, I'm going to do the tests. Thank you.
I've been looking at this and other related problems the last few days. I've got a fix for a part of it, for which I'll probably be sending a patch tomorrow or the day after. The fixed part was as follows: 1. For some reason we have the well-known name owned by someone, but this someone doesn't answer connections. 2. We have timeouts, making startup slow. 3. After the timeouts, we try to take ownership of the name, which is probably reasonable. 4. We make a mistake. We use g_dbus_own_name and take its return value as meaningful proof that we're now the owner, when it always returns non-zero and is asynchronous. We have no idea if we own the name until after we run gtk_main_loop. 5. We think we own the name, and thus are the server, so we must not die on close. 6. Rinse and repeat. The fix consists in using explicit messages to get ownership (or have our request rejected) synchronously. From what I've read on mailing lists, GDBus sets the policy of async requests being the one true way, so no helpers. I also set it so no queue happens, since that follows better with the actual flow of the current implementation. I'm rethinking the flow to see if I can understand and avoid the causes of the server freeze in the first place.
The same issue explains the multiple windows, too. Process A sees itself as the owner. It has 0 windows open, since it's just been created. So, if it opens a window, it will be the only one. When process B starts and thinks it's the owner, it'll do the same. Plus, the actual owner may not be answering, but that doesn't necessarily mean it isn't listening, so you may see its window, too.
Simple steps to reproduce (written in a way that can just be copied to the terminal): # Kill any server that may be already running. Use `pkill -9` in case it's hanged up or something. pkill -9 xfce4-appfinder # Launch our own server. xfce4-appfinder & # Make sure it has enough time to take ownership of the name. sleep 1 # Freeze it. # You could close the window before this if you want. # It doesn't matter, but having the windows is ugly. # If the OS tells you that it hanged and offers you to close it, say no. kill -TSTP $! # Start a few launchers in the background. for i in {1..5}; do (xfce4-appfinder &); sleep 1; done # Now, close all of the windows that appeared. # It has to be done by hand. # Count how many processes we have now: pgrep -a xfce4-appfinder The fix I proposed fixes the persistence of the processes, but fixing the multiple windows appearing is both a matter of policy and a matter of diagnosing what causes the server hang in the first place. The bit about policy is essentially a call for either never spawning windows outside of the name owner or accepting that the server could fail and fall back to launching the window when it times out. The prior would mean that, once the server hangs, no other appfinder window will appear until it's killed, which is probably undesirable.
I created a bug report for the crash which was mentioned in comment #2. Bug 15679
@Mario thanks for the investigation, it seems the root cause of OP's problem is that appfinder is frozen, we need to fix that, I'm not inclined to change how appfinder handles this scenario, IMHO it's good enough for such rare conditions. As matter of fact, every other app trying to own a dbus name would have to be reviewed. @Bastián as pointed by Theo, Bug #15679 could be related, the fix is already in git master, if you could build garcon and try it out would be very helpful for us to confirm this is freezing appfinder.
Created attachment 8733 Determine bus name ownership synchronously. The main control flow assumes ownership is dealt with before the main loop. The current implementation makes this impossible, and always informs success. This patch fixes this. The consequence is that appfinder no long spam servers when there's any issue with D-Bus.
I think avoiding spamming of processes is worth the time. Specially considering it won't only trigger due to appfinder's own bugs, but any kind of system issue that causes timeouts on message delivery or answering (maybe high load?) would trigger this. On the condition being rare, I'm not sure it is. I came here because I experienced the same problem, after Googling and the only 'solution' I found on the net was to just disable the server and spawning each process explicitly as their own. The attached patch fixes part of the problem, and doesn't change anything other than how appfinder determines whether or not it's the server.
On the hang, I advise on a procedure like the following (assuming the server already shows symptoms): - Install strace, platform dependant. Never used RH-based distros. - Determine the actual server. No idea of a reliable way, but the lowest pid seems like a good heuristic. $ appfinder_server=$(pgrep xfce4-appfinder | sort -n | head -1) - Attach strace to it and check what's it waiting for. $ sudo strace -p $appfinder_server Getting a gdb backtrace may help, too. I may comment on that later.
I got to reproduce the issue and found an infinite loop when refreshing the actions related to an item. The actions list got corrupted, pointing to itself, so iteration would never end. I think the cause is fixed by this commit in libgarcon: https://git.xfce.org/xfce/garcon/commit?id=6f452937366bb1599fb0ae986958786d52946f15
Oh, I just realized is the fix you mentioned before. Anyway, I think I can confirm it was that, now.
I'm closing this issue because it was very likely a bug in garcon. @Mario, can you please file another bug for you patch? After 4.14 I hope to have the time to properly review its implications. Thanks.