Change:
{ fetchFromGitHub <ins> , fetchpatch </ins> , glib , gobject-introspection , meson

Discussion:
Several windows of nemo closing together when sending killactive (note that this is not real kill) and a coredump can be found in systemd journal. Steps to reproduce the behavior: several instances of nemo from a wlroots based compositor e.g. sway or hyprland. hotkeys attached to killactive on one window. systemd-coredump message from journal (I use gnome-logs for convenience). The nemo window should exits one per time, not closing together, and not coredump as well. windows do share one process id, but this seems to be not the case as . (however, this may be misleading as someone mentioned that steam also exits its background process when using killactive) issue didn't exist on Arch Linux. Just to mention that there may be something we should patch. is the content of coredump: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Reported from Fedora with nemo 5.6.2, also hyprland, works fine.
More related behavior (I'll call nemo windows in time order as nemo1 nemo2 etc): I launch nemo1 and nemo2 in a short interval, they won't close together when I close one. I launch nemo1 and wait for about 10 seconds, then launch nemo2, then close nemo1, they are possible to crash. However, closing nemo2 immediately won't, if wait for another 10 seconds, both crashes when closing nemo1 or nemo2. I launch nemo1, nemo2 and nemo3 in a short interval, then close nemo1, they all will crash. Again, nemo windows share one pid. So the crash will close all windows. This was , but I'm afraid they can't reproduce the bug anymore. Also since other distros can't reproduce this bug, I'd rather believe it's specific to nixos, and maybe because of the wrapper.

I was not able to properly test this right now (sorry :bowingwoman:), but here are some random things you can try: See if you can reproduce this with nautilus, thunar, also some old version of nemo, some old nixpkgs checkouts, ... If you find it previously working, a bisect point will be appreciated. Install debug symbols and reproduce the crash, not tested but should be something like: Then get list of crashes with , run and enter . Based on the above step, try to patch away (remove) some of the lines in  according to your stack trace and try reproduce the issue, you can also e.g. try swapping the order they distroy widgets to see if it matters. Sorry I have no idea how killactive "closes" a window, is that the only way to trigger the crash? Did you spot the crash when closing nemo normally, i.e. clicking (File) - (Close All Windows) and/or (File) - (Close)?
Sorry I haven't got time to debug it, but I've tested with "close all windows" or "close" several times, they didn't crash and "close" works correctly. Thunar don't (since it doesn't share the same pid across windows?), and nautilus refuses to open a second window when one exists.
Okay here is the coredump:
Weird, did you trigger the crash after rebuilding nemo? :thinking:
Yes, by the same killactive sended by hyprland
in my nixos configuration, and installed with home manager (home manager as a module of nixos). This rebuilds nemo (I saw it) when applying config.
Can you try adding to () instead?
Okay it seem to work, and now I get this:
Pretty fun though, it happens even without triggering the 'search window'. I just open and close the nemo, and do nothing else.
Make sense to me! If I hit the search button to trigger the search widget, then close it, it won't crash (tested 10 times). So the problem is trying to destroy a widget that doesn't exist.

However, there is another question: fedora and archlinux with the exact nemo 5.6.3, hyprland latest, xdg-desktop-portal-hyprland, doesn't, and the code makes sense. So what is happening to nixos?
Unsure of memory leaks, but anyway it works. This seems like a upstream bug and caused by gtk or glib version compatibility. Will close it for now.
Hmmm, please consider reporting this to linuxmint. I checked nautilus and they after so we are on our own. I actually wonder whether a check is needed But it is unclear to me why the null check is not enough :upsidedown_face:
Tested, this is not enough however.
Did this ever get fixed? I seem to be having this same issue still with version 6.0.2
I totally forgot that. I'm using my patches for more than one year. This is also useful for Would be better to report it upstream, though.
Thanks for the info. This does in fact fix it. It's worth noting for anyone who might travel this path in the future - the patch has to be applied to , even if using . Totally didn't spend 45 minutes trying to figure out why it wasn't working just to figure that out
Please try .
seems to work?