glib2-2.80.2-1.1-x86_64 and/or lib32-glib2-2.80.2 are causing mousepad to segfault. I fixed the problem by downgrading to glib2-2.80.0-4.1-x86_64 and lib32-glib2-2.80.0-4-x86_64.
Here is the dmesg output from 2 different glib2-2.80.2 segfaults:
Yes, I have tried both the 2.80.0 and 2.80.2 versions of glib2, lib32-glib2, and glib2-docs multiple times. I’ve also uninstalled mousepad with pacman -Rns, and removed ~/.config/Mousepad, each time. But no matter what I try mousepad segfaults with 2.80.2.
The most interesting thing is that I have two systems running CachyOS with all the latest updates, a media server and a workstation, and the problem only occurs on my workstation.
The media server utilizes an ASRock B550M-ITX motherboard, Ryzen 5 4600G CPU, and 2x8GB CMK16GX4M2Z3200C16 Corsair Vengeance DDR4 DRAM.
My workstation utilizes an ASUS TUF Gaming X570-PLUS motherboard, Ryzen 7 5700X CPU, and 2x16GB CMW32GX4M2D3600C18 Corsair Vengeance DDR4 DRAM.
And of course both motherboards have the latest BIOS.
I’m a retired R&D engineer so before filing the bug I suspected there was some type of hardware error with my workstation, but after running mprime for 2 hours, and memtest86±efi overnight, there were no errors. I also ran most all the software I could, including a full passthrough Windows 10 VM, GPU passthrough Windows 11 VM, and console Windows 10 VM with Qemu/KVM and everything runs perfectly. Of course I’ve been checking dmesg for errors as well as visual inspection.
But for some reason mousepad is the only software that segfaults with 2.80.2, and only on my workstation. It’s really baffling.
But I’m more than willing and capable of helping debug the issue in any way you’d like. But for now I’m out of ideas. strace didn’t lead me anywhere but to glib, but maybe gdb could assist? You’d just have to instruct me on the debugging steps.
I’ll try using the Arch versions of glib2 and if the same problem occurs I’ll report it to GitLab. I reported it to CachyOS as they come from your custom repository, and I was hoping it was either some kind of already known issue, or you could diagnose the problem from the code string which is common among all mousepad segfaults.
I tried for quite awhile to login to both Gnome GitLab and GitLab yesterday, as I know I’ve registered at GitLab, and thought I’d registered at Gnome GitLab, but they wouldn’t accept my password and I couldn’t get a reset email. So then I tried creating a new account but couldn’t get a confirmation email so I gave up.
However I got an email from Gnome GitLab this morning and they said they were having Captcha problems, and intimated it was fixed, but I still can’t login or get a new account confirmation email even though the Captcha is now appearing. So I don’t know what to do. I simply can’t get through to them.
But if I ever do I’ll post the link to the bug report here. However it doesn’t look good, it seems they’re having major problems.
EDIT:
I just sent the bug report to the support link that told my about the Captcha problem. I told them they’re system still isn’t working and requested a link to the bug report if they enter it for me. For now that’s all I can do.
Okay, Gnome GitLab created an account for me. Here’s a post to the bug report. You’ll see that it was also reported on the Arch Linux forums, along with a patch that supposedly fixes it, so hopefully a new version will be released soon.
I just wanted to make sure you’re aware that this issue uncovered a few other errors and the fix was more complex than the initial patch supplied by loqs. A few gnome developers looked at the problem and patched multiple files, and they’ve been merged into main.
So I downloaded the CachyOS package builds with yay -G, changed pkgrel to 3, changed the first source array to “git+https://gitlab.gnome.org/GNOME/glib.git”, the b2sums to SKIP, and then compiled and installed the resulting glib2 and lib32-glib2 packages. Then I ran mousepad, most of my other software including my VMs, and everything seems to work.
Of course the initial patch by loqs also seemed to work so my anecdotal tests don’t appear to mean much, but I just wanted to make sure you knew the actual gnome devs seem to have fixed the problem.
The main milestone has been changed to 2.80.3 so hopefully an official change will be released soon.
I’m happy to help, and can’t tell you how appreciative I am of all the CachyOS devs. The distro you’ve created is absolutely awesome!
However if possible it would be great if you could get hold of the gnome devs before pushing the patch. It’s working great for me, but as you saw they discovered some significant problems, and I’d hate for something to go wrong because I made some type of error, or there’s software I don’t have that’s affected by it.
On the other hand the current glib2 is breaking a lot of things, and it’s important that it be fixed ASAP. So I’m sure glad I’m not in your position! The build itself does a lot of tests and since they passed it seems like it would be okay, but they passed with the broken version as well so more tests definitely need to be added.
In any case I’ll keep my eye out for any problems, and my fingers crossed as well
I had time today to replace my custom 20.80.2-3 build pulled from main a few days ago with your backported 2.80.2.1 package and performed the same verifications as before and there were no errors. Thanks for addressing the issue so quickly.
The build itself does a lot of tests and since they passed it seems like it would be okay, but they passed with the broken version as well so more tests definitely need to be added.