Description of problem: Xorg segfaults on an aarch64 (16k page size) system. Version-Release number of selected component (if applicable): libunwind 1.6.2-2 How reproducible: Always Steps to Reproduce: 1. launch xorg on an Apple M1/M2 system. Actual results: libunwind causes Xorg to segfault with the following: Stack trace of thread 905: #0 0x0000ffff55143a38 access_mem (libunwind.so.8 + 0x3a38) #1 0x000fffff551495ec n/a (n/a + 0x0) #2 0x000fffff551495ec n/a (n/a + 0x0) #3 0x0005aaaab39efcac n/a (n/a + 0x0) #4 0x0069aaaab39f1a54 n/a (n/a + 0x0) #5 0x002fffff5570c7ec n/a (n/a + 0x0) #6 0x0031ffff551495ec n/a (n/a + 0x0) #7 0x0031ffff551495ec n/a (n/a + 0x0) #8 0x007bffff55149ab0 n/a (n/a + 0x0) #9 0x0060aaaab39f40fc n/a (n/a + 0x0) #10 0x0022aaaab388b81c n/a (n/a + 0x0) #11 0x0017ffff54bd73c8 n/a (n/a + 0x0) #12 0x0026ffff54bd74a0 n/a (n/a + 0x0) #13 0x003eaaaab388c6f0 n/a (n/a + 0x0) ELF object binary architecture: AARCH64 Expected results: No segfault. Additional info: This issue affects Apple M1/M2 systems -- which support 16k and 64k page sizes https://github.com/AsahiLinux/docs/wiki/Broken-Software This PR resovles the issue by enabling dynamic page support for all archs: https://github.com/libunwind/libunwind/commit/e85b65cec757ef589f28957d0c6c21c498a03bdf Arch Linux also ran into the same issue: https://github.com/archlinuxarm/PKGBUILDs/pull/1922 This would obviously be resolved with a version bump of libunwind, but I have no idea when that would happen and I'd really like to ensure this fix is resolved in F37. I've included that patch in my own local repo here. https://www.leifliddy.com/asahi-linux/36/source/SRPMS/libunwind-1.6.2-3.fc36.src.rpm This has been thoroughly tested on an Apple M1 system.
This should be fixed in libunwind-1.6.2-4.fc38. The general state of the test suite isn't great, though, which makes me worried. Do we need to apply the fix to older branches as well? Thanks.
>Do we need to apply the fix to older branches as well? Yes, we should definitely apply it to F37 (and probably F36 as well) -- but I don't think there's any compelling reason to go back further than that. Should I submit new PR's for those branches? >The general state of the test suite isn't great, though, which makes me worried. What's wrong with the test suite? It looks like is passed everything.
Ok, I merged the 1.6.2-4 changes to the F37 branch and submitted a PR for that. Can you please take a look at it when you get a chance?
FEDORA-2022-3b74e12e7c has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3b74e12e7c
FEDORA-2022-3b74e12e7c has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-3b74e12e7c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3b74e12e7c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-3b74e12e7c has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.