* [musl] Segmentation fault musl 1.2.4
@ 2023-12-20 21:53 Cody Wetzel
2023-12-21 3:38 ` Rich Felker
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Cody Wetzel @ 2023-12-20 21:53 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
Hello,
I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP
updated the pagesize to 32k and I believe musl isn't handling it
gracefully. musl 1.2.3 does not have this problem.
https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices
Please CC me.
--
Cody Wetzel
codyawetzel@gmail.com
(402)490-9242
[-- Attachment #2: Type: text/html, Size: 893 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [musl] Segmentation fault musl 1.2.4 2023-12-20 21:53 [musl] Segmentation fault musl 1.2.4 Cody Wetzel @ 2023-12-21 3:38 ` Rich Felker 2023-12-21 4:15 ` Rich Felker 2023-12-21 7:57 ` Markus Wichmann 2023-12-22 2:20 ` [musl] Segmentation fault musl 1.2.4 Jeffrey Walton 2 siblings, 1 reply; 26+ messages in thread From: Rich Felker @ 2023-12-21 3:38 UTC (permalink / raw) To: Cody Wetzel; +Cc: musl On Wed, Dec 20, 2023 at 03:53:38PM -0600, Cody Wetzel wrote: > Hello, > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP > updated the pagesize to 32k and I believe musl isn't handling it > gracefully. musl 1.2.3 does not have this problem. > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > Please CC me. Without any indication of where the segfault was, it's impossible to know whether it has anything to do with the change you cited or even with musl. There is no reason oversized pages shouldn't function with musl. They will lead to significantly worse memory usage and possibly worse performance, but of course should not crash. Using 4k pages is highly recommended if you have the option. If you think the crash is caused by or related to a bug in musl, please report what application is crashing and let us know if you can use a debugger to get some basic information on the location of the crash. Rich ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-21 3:38 ` Rich Felker @ 2023-12-21 4:15 ` Rich Felker 0 siblings, 0 replies; 26+ messages in thread From: Rich Felker @ 2023-12-21 4:15 UTC (permalink / raw) To: Cody Wetzel; +Cc: musl On Wed, Dec 20, 2023 at 10:38:01PM -0500, Rich Felker wrote: > On Wed, Dec 20, 2023 at 03:53:38PM -0600, Cody Wetzel wrote: > > Hello, > > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP > > updated the pagesize to 32k and I believe musl isn't handling it > > gracefully. musl 1.2.3 does not have this problem. > > > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > > > Please CC me. I did CC but your mail provider is refusing the mail. Can you please complain to them? Rich ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-20 21:53 [musl] Segmentation fault musl 1.2.4 Cody Wetzel 2023-12-21 3:38 ` Rich Felker @ 2023-12-21 7:57 ` Markus Wichmann 2023-12-21 18:39 ` Cody Wetzel 2023-12-22 2:20 ` [musl] Segmentation fault musl 1.2.4 Jeffrey Walton 2 siblings, 1 reply; 26+ messages in thread From: Markus Wichmann @ 2023-12-21 7:57 UTC (permalink / raw) To: musl; +Cc: Cody Wetzel Am Wed, Dec 20, 2023 at 03:53:38PM -0600 schrieb Cody Wetzel: > Hello, > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP > updated the pagesize to 32k and I believe musl isn't handling it > gracefully. musl 1.2.3 does not have this problem. > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > Please CC me. > > -- > Cody Wetzel > codyawetzel@gmail.com > (402)490-9242 Gonna try my luck since Rich apparently had none: Please procure some data from the crash, such as a core dump or a backtrace. Without any indication of what is going on, there is no telling whether the issue you are experiencing even is in musl, let alone where it is. BTW, the linked website is a hoot and a half. "We made this change to improve your user experience, but it may cause your applications to have less memory and also crash. Your only recourse is to 'Verify compatibility', i.e. sink or swim." Ciao, Markus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-21 7:57 ` Markus Wichmann @ 2023-12-21 18:39 ` Cody Wetzel 2023-12-21 21:25 ` Natanael Copa 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2023-12-21 18:39 UTC (permalink / raw) To: Markus Wichmann; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 1677 bytes --] Markus, No kidding. I've been dealing with issues running Home Assistant for quite some time thanks to this page size change. Since I'm not the most well versed in Linux I will need to look into how to get logs. I do have a Github issue you can look at for more details in the meantime. https://github.com/home-assistant/core/issues/86589 Note that I think there is an issue in rustc also. Thanks! Cody On Thu, Dec 21, 2023 at 1:57 AM Markus Wichmann <nullplan@gmx.net> wrote: > Am Wed, Dec 20, 2023 at 03:53:38PM -0600 schrieb Cody Wetzel: > > Hello, > > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. > QNAP > > updated the pagesize to 32k and I believe musl isn't handling it > > gracefully. musl 1.2.3 does not have this problem. > > > > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > > > Please CC me. > > > > -- > > Cody Wetzel > > codyawetzel@gmail.com > > (402)490-9242 > > Gonna try my luck since Rich apparently had none: Please procure some > data from the crash, such as a core dump or a backtrace. Without any > indication of what is going on, there is no telling whether the issue > you are experiencing even is in musl, let alone where it is. > > BTW, the linked website is a hoot and a half. "We made this change to > improve your user experience, but it may cause your applications to have > less memory and also crash. Your only recourse is to 'Verify > compatibility', i.e. sink or swim." > > Ciao, > Markus > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 2681 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-21 18:39 ` Cody Wetzel @ 2023-12-21 21:25 ` Natanael Copa 2023-12-21 21:57 ` Cody Wetzel 0 siblings, 1 reply; 26+ messages in thread From: Natanael Copa @ 2023-12-21 21:25 UTC (permalink / raw) To: Cody Wetzel; +Cc: musl, Markus Wichmann On Thu, 21 Dec 2023 12:39:35 -0600 Cody Wetzel <codyawetzel@gmail.com> wrote: > Markus, > > No kidding. I've been dealing with issues running Home Assistant for quite > some time thanks to this page size change. Since I'm not the most well > versed in Linux I will need to look into how to get logs. I do have a > Github issue you can look at for more details in the meantime. > > https://github.com/home-assistant/core/issues/86589 Those issues will keep popping up til we fix them, and to fix them we will need to know exactly what to fix, a backtrace may help with that. Alternatively we'd need a simple way to reproduce the issue. I found this following the above issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15167 This issue looks more like a problem in busybox than musl. -nc > Note that I think there is an issue in rustc also. > > Thanks! > > Cody > > On Thu, Dec 21, 2023 at 1:57*AM Markus Wichmann <nullplan@gmx.net> > wrote: > > > Am Wed, Dec 20, 2023 at 03:53:38PM -0600 schrieb Cody Wetzel: > > > Hello, > > > > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP > > > NAS. > > QNAP > > > updated the pagesize to 32k and I believe musl isn't handling it > > > gracefully. musl 1.2.3 does not have this problem. > > > > > > > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > > > > > > > Please CC me. > > > > > > -- > > > Cody Wetzel > > > codyawetzel@gmail.com > > > (402)490-9242 > > > > Gonna try my luck since Rich apparently had none: Please procure > > some data from the crash, such as a core dump or a backtrace. > > Without any indication of what is going on, there is no telling > > whether the issue you are experiencing even is in musl, let alone > > where it is. > > > > BTW, the linked website is a hoot and a half. "We made this change > > to improve your user experience, but it may cause your applications > > to have less memory and also crash. Your only recourse is to 'Verify > > compatibility', i.e. sink or swim." > > > > Ciao, > > Markus > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-21 21:25 ` Natanael Copa @ 2023-12-21 21:57 ` Cody Wetzel 2024-01-03 17:20 ` Cody Wetzel 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2023-12-21 21:57 UTC (permalink / raw) To: Natanael Copa; +Cc: musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 2836 bytes --] I am able to run: # apk upgrade busybox --repository= https://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository=https://dl-cd n.alpinelinux.org/alpine/v3.18/community and not create a segmentation fault on Alpine 3.17 I will be on Christmas vacation for the next week but when I get back I can try to get additional details. Thanks! Cody On Thu, Dec 21, 2023 at 3:25 PM Natanael Copa <ncopa@alpinelinux.org> wrote: > On Thu, 21 Dec 2023 12:39:35 -0600 > Cody Wetzel <codyawetzel@gmail.com> wrote: > > > Markus, > > > > No kidding. I've been dealing with issues running Home Assistant for > quite > > some time thanks to this page size change. Since I'm not the most well > > versed in Linux I will need to look into how to get logs. I do have a > > Github issue you can look at for more details in the meantime. > > > > https://github.com/home-assistant/core/issues/86589 > > Those issues will keep popping up til we fix them, and to fix them we > will need to know exactly what to fix, a backtrace may help with that. > Alternatively we'd need a simple way to reproduce the issue. > > I found this following the above issue: > https://gitlab.alpinelinux.org/alpine/aports/-/issues/15167 > This issue looks more like a problem in busybox than musl. > > -nc > > > > Note that I think there is an issue in rustc also. > > > > Thanks! > > > > Cody > > > > On Thu, Dec 21, 2023 at 1:57*AM Markus Wichmann <nullplan@gmx.net> > > wrote: > > > > > Am Wed, Dec 20, 2023 at 03:53:38PM -0600 schrieb Cody Wetzel: > > > > Hello, > > > > > > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP > > > > NAS. > > > QNAP > > > > updated the pagesize to 32k and I believe musl isn't handling it > > > > gracefully. musl 1.2.3 does not have this problem. > > > > > > > > > > > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > > > > > > > > > > Please CC me. > > > > > > > > -- > > > > Cody Wetzel > > > > codyawetzel@gmail.com > > > > (402)490-9242 > > > > > > Gonna try my luck since Rich apparently had none: Please procure > > > some data from the crash, such as a core dump or a backtrace. > > > Without any indication of what is going on, there is no telling > > > whether the issue you are experiencing even is in musl, let alone > > > where it is. > > > > > > BTW, the linked website is a hoot and a half. "We made this change > > > to improve your user experience, but it may cause your applications > > > to have less memory and also crash. Your only recourse is to 'Verify > > > compatibility', i.e. sink or swim." > > > > > > Ciao, > > > Markus > > > > > > > > > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 4654 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-21 21:57 ` Cody Wetzel @ 2024-01-03 17:20 ` Cody Wetzel 2024-01-03 17:26 ` Leah Neukirchen 2024-01-04 14:48 ` Szabolcs Nagy 0 siblings, 2 replies; 26+ messages in thread From: Cody Wetzel @ 2024-01-03 17:20 UTC (permalink / raw) To: Natanael Copa; +Cc: musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 4508 bytes --] Hello musl team, I tried getting a core dump but I'm not sure if I'm doing something wrong... / # cat /proc/sys/kernel/core_pattern/tmp/core-%e-%s-%u-%g-%p-%t/ # apk upgrade busybox --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communityfetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/armv7/APKINDEX.tar.gzfetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gzfetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/armv7/APKINDEX.tar.gzfetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/armv7/APKINDEX.tar.gz(1/3) Upgrading busybox (1.35.0-r29 -> 1.36.1-r5)Executing busybox-1.36.1-r5.post-upgrade(2/3) Upgrading busybox-binsh (1.35.0-r29 -> 1.36.1-r5)(3/3) Upgrading ssl_client (1.35.0-r29 -> 1.36.1-r5)Executing busybox-1.36.1-r5.triggerOK: 5 MiB in 15 packages/ # apk upgrade musl --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/community(1/1) Upgrading musl (1.2.3-r5 -> 1.2.4-r2)OK: 5 MiB in 15 packages/ # apk upgrade rust --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communitySegmentation fault/ # apk -hSegmentation fault/ # ls /tmp/core*Segmentation fault/ # cd /tmp/tmp # lsSegmentation fault > > Thanks! Cody On Thu, Dec 21, 2023 at 3:57 PM Cody Wetzel <codyawetzel@gmail.com> wrote: > I am able to run: > > # apk upgrade busybox --repository= > https://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository= > https://dl-cd > n.alpinelinux.org/alpine/v3.18/community > > and not create a segmentation fault on Alpine 3.17 > > I will be on Christmas vacation for the next week but when I get back I > can try to get additional details. > > Thanks! > > Cody > > On Thu, Dec 21, 2023 at 3:25 PM Natanael Copa <ncopa@alpinelinux.org> > wrote: > >> On Thu, 21 Dec 2023 12:39:35 -0600 >> Cody Wetzel <codyawetzel@gmail.com> wrote: >> >> > Markus, >> > >> > No kidding. I've been dealing with issues running Home Assistant for >> quite >> > some time thanks to this page size change. Since I'm not the most well >> > versed in Linux I will need to look into how to get logs. I do have a >> > Github issue you can look at for more details in the meantime. >> > >> > https://github.com/home-assistant/core/issues/86589 >> >> Those issues will keep popping up til we fix them, and to fix them we >> will need to know exactly what to fix, a backtrace may help with that. >> Alternatively we'd need a simple way to reproduce the issue. >> >> I found this following the above issue: >> https://gitlab.alpinelinux.org/alpine/aports/-/issues/15167 >> This issue looks more like a problem in busybox than musl. >> >> -nc >> >> >> > Note that I think there is an issue in rustc also. >> > >> > Thanks! >> > >> > Cody >> > >> > On Thu, Dec 21, 2023 at 1:57*AM Markus Wichmann <nullplan@gmx.net> >> > wrote: >> > >> > > Am Wed, Dec 20, 2023 at 03:53:38PM -0600 schrieb Cody Wetzel: >> > > > Hello, >> > > > >> > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP >> > > > NAS. >> > > QNAP >> > > > updated the pagesize to 32k and I believe musl isn't handling it >> > > > gracefully. musl 1.2.3 does not have this problem. >> > > > >> > > > >> > > >> https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices >> > > >> > > > >> > > > Please CC me. >> > > > >> > > > -- >> > > > Cody Wetzel >> > > > codyawetzel@gmail.com >> > > > (402)490-9242 >> > > >> > > Gonna try my luck since Rich apparently had none: Please procure >> > > some data from the crash, such as a core dump or a backtrace. >> > > Without any indication of what is going on, there is no telling >> > > whether the issue you are experiencing even is in musl, let alone >> > > where it is. >> > > >> > > BTW, the linked website is a hoot and a half. "We made this change >> > > to improve your user experience, but it may cause your applications >> > > to have less memory and also crash. Your only recourse is to 'Verify >> > > compatibility', i.e. sink or swim." >> > > >> > > Ciao, >> > > Markus >> > > >> > >> > >> >> > > -- > Cody Wetzel > codyawetzel@gmail.com > (402)490-9242 > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 9559 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-03 17:20 ` Cody Wetzel @ 2024-01-03 17:26 ` Leah Neukirchen 2024-01-03 18:00 ` Cody Wetzel 2024-01-04 14:48 ` Szabolcs Nagy 1 sibling, 1 reply; 26+ messages in thread From: Leah Neukirchen @ 2024-01-03 17:26 UTC (permalink / raw) To: Cody Wetzel; +Cc: musl Cody Wetzel <codyawetzel@gmail.com> writes: > Hello musl team, > > I tried getting a core dump but I'm not sure if I'm doing something wrong... You need to run % ulimit -c unlimited to enable coredumps for the session. -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-03 17:26 ` Leah Neukirchen @ 2024-01-03 18:00 ` Cody Wetzel 0 siblings, 0 replies; 26+ messages in thread From: Cody Wetzel @ 2024-01-03 18:00 UTC (permalink / raw) To: Leah Neukirchen; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 751 bytes --] I thought I had tried that command and just to confirm I tried it again. I receive no core dump however. To further clarify, even if a core dump did occur using all basic commands result in segfault after upgrading musl. I can't use ls or mv for example. Thanks! Cody On Wed, Jan 3, 2024 at 11:26 AM Leah Neukirchen <leah@vuxu.org> wrote: > Cody Wetzel <codyawetzel@gmail.com> writes: > > > Hello musl team, > > > > I tried getting a core dump but I'm not sure if I'm doing something > wrong... > > You need to run > > % ulimit -c unlimited > > to enable coredumps for the session. > > -- > Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/ > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 1495 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-03 17:20 ` Cody Wetzel 2024-01-03 17:26 ` Leah Neukirchen @ 2024-01-04 14:48 ` Szabolcs Nagy 2024-01-10 15:59 ` Cody Wetzel 1 sibling, 1 reply; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-04 14:48 UTC (permalink / raw) To: Cody Wetzel; +Cc: Natanael Copa, musl, Markus Wichmann * Cody Wetzel <codyawetzel@gmail.com> [2024-01-03 11:20:29 -0600]: > Hello musl team, > > I tried getting a core dump but I'm not sure if I'm doing something wrong... > > / # cat /proc/sys/kernel/core_pattern/tmp/core-%e-%s-%u-%g-%p-%t/ # > apk upgrade busybox > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communityfetch > https://dl-cdn.alpinelinux.org/alpine/v3.18/community/armv7/APKINDEX.tar.gzfetch > https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gzfetch > https://dl-cdn.alpinelinux.org/alpine/v3.17/main/armv7/APKINDEX.tar.gzfetch > https://dl-cdn.alpinelinux.org/alpine/v3.17/community/armv7/APKINDEX.tar.gz(1/3) > Upgrading busybox (1.35.0-r29 -> 1.36.1-r5)Executing > busybox-1.36.1-r5.post-upgrade(2/3) Upgrading busybox-binsh > (1.35.0-r29 -> 1.36.1-r5)(3/3) Upgrading ssl_client (1.35.0-r29 -> > 1.36.1-r5)Executing busybox-1.36.1-r5.triggerOK: 5 MiB in 15 packages/ > # apk upgrade musl > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/community(1/1) > Upgrading musl (1.2.3-r5 -> 1.2.4-r2)OK: 5 MiB in 15 packages/ # apk > upgrade rust --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communitySegmentation > fault/ # apk -hSegmentation fault/ # ls /tmp/core*Segmentation fault/ > # cd /tmp/tmp # lsSegmentation fault i'd # cp /lib/ld-musl-armhf.so.1 /tmp # apk add gdb musl-dbg apk-tools-static then upgrade musl using apk.static, then debug via # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp or analyze a core dump, you can always install more debug tools via apk.static and run commands using the old ld-musl-armhf.so.1 in gdb, you want to do bt disas $pc-40,+80 info reg info proc map as a starting point and post the results. strace output can be useful too as well as readelf -aW of ld.so depending on what is going on. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-04 14:48 ` Szabolcs Nagy @ 2024-01-10 15:59 ` Cody Wetzel 2024-01-11 17:03 ` Szabolcs Nagy 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2024-01-10 15:59 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 5319 bytes --] So maybe I'm not understanding how gdb works or is used. I'm getting no meaningful output even though these commands should result in a segmentation fault. > / # gdb > Segmentation fault > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > GNU gdb (GDB) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv7-alpine-linux-musleabihf". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ls... > (No debugging symbols found in ls) > (gdb) > quit > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args cd /tmp > GNU gdb (GDB) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv7-alpine-linux-musleabihf". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > cd: No such file or directory. > (gdb) > quit > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args apk -h /tmp > GNU gdb (GDB) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv7-alpine-linux-musleabihf". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from apk... > (No debugging symbols found in apk) > (gdb) bt > No stack. > (gdb) disas $pc-40,+80 > No registers. > (gdb) info reg > The program has no registers now. On Thu, Jan 4, 2024 at 8:48 AM Szabolcs Nagy <nsz@port70.net> wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-03 11:20:29 -0600]: > > Hello musl team, > > > > I tried getting a core dump but I'm not sure if I'm doing something > wrong... > > > > / # cat /proc/sys/kernel/core_pattern/tmp/core-%e-%s-%u-%g-%p-%t/ # > > apk upgrade busybox > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communityfetch > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/community/armv7/APKINDEX.tar.gzfetch > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gzfetch > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/main/armv7/APKINDEX.tar.gzfetch > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/community/armv7/APKINDEX.tar.gz(1/3) > > Upgrading busybox (1.35.0-r29 -> 1.36.1-r5)Executing > > busybox-1.36.1-r5.post-upgrade(2/3) Upgrading busybox-binsh > > (1.35.0-r29 -> 1.36.1-r5)(3/3) Upgrading ssl_client (1.35.0-r29 -> > > 1.36.1-r5)Executing busybox-1.36.1-r5.triggerOK: 5 MiB in 15 packages/ > > # apk upgrade musl > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/community(1/1) > > Upgrading musl (1.2.3-r5 -> 1.2.4-r2)OK: 5 MiB in 15 packages/ # apk > > upgrade rust --repository= > https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > --repository= > https://dl-cdn.alpinelinux.org/alpine/v3.18/communitySegmentation > > fault/ # apk -hSegmentation fault/ # ls /tmp/core*Segmentation fault/ > > # cd /tmp/tmp # lsSegmentation fault > > i'd > > # cp /lib/ld-musl-armhf.so.1 /tmp > # apk add gdb musl-dbg apk-tools-static > > then upgrade musl using apk.static, then debug via > > # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > or analyze a core dump, you can always install more debug tools > via apk.static and run commands using the old ld-musl-armhf.so.1 > > in gdb, you want to do > > bt > disas $pc-40,+80 > info reg > info proc map > > as a starting point and post the results. > > strace output can be useful too as well as readelf -aW of ld.so > depending on what is going on. > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 13019 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-10 15:59 ` Cody Wetzel @ 2024-01-11 17:03 ` Szabolcs Nagy 2024-01-11 18:19 ` Cody Wetzel 0 siblings, 1 reply; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-11 17:03 UTC (permalink / raw) To: Cody Wetzel; +Cc: Natanael Copa, musl, Markus Wichmann * Cody Wetzel <codyawetzel@gmail.com> [2024-01-10 09:59:18 -0600]: > So maybe I'm not understanding how gdb works or is used. you have to run the process.. you never issued the gdb 'run' command. > I'm getting no > meaningful output even though these commands should result in a > segmentation fault. > > > / # gdb > > Segmentation fault > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > GNU gdb (GDB) 12.1 > > Copyright (C) 2022 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from ls... > > (No debugging symbols found in ls) > > (gdb) > > quit > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args cd /tmp > > GNU gdb (GDB) 12.1 > > Copyright (C) 2022 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > cd: No such file or directory. > > (gdb) > > quit > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args apk -h /tmp > > GNU gdb (GDB) 12.1 > > Copyright (C) 2022 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from apk... > > (No debugging symbols found in apk) > > (gdb) bt > > No stack. > > (gdb) disas $pc-40,+80 > > No registers. > > (gdb) info reg > > The program has no registers now. > > > On Thu, Jan 4, 2024 at 8:48 AM Szabolcs Nagy <nsz@port70.net> wrote: > > > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-03 11:20:29 -0600]: > > > Hello musl team, > > > > > > I tried getting a core dump but I'm not sure if I'm doing something > > wrong... > > > > > > / # cat /proc/sys/kernel/core_pattern/tmp/core-%e-%s-%u-%g-%p-%t/ # > > > apk upgrade busybox > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/communityfetch > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/community/armv7/APKINDEX.tar.gzfetch > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gzfetch > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/main/armv7/APKINDEX.tar.gzfetch > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/community/armv7/APKINDEX.tar.gz(1/3) > > > Upgrading busybox (1.35.0-r29 -> 1.36.1-r5)Executing > > > busybox-1.36.1-r5.post-upgrade(2/3) Upgrading busybox-binsh > > > (1.35.0-r29 -> 1.36.1-r5)(3/3) Upgrading ssl_client (1.35.0-r29 -> > > > 1.36.1-r5)Executing busybox-1.36.1-r5.triggerOK: 5 MiB in 15 packages/ > > > # apk upgrade musl > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/community(1/1) > > > Upgrading musl (1.2.3-r5 -> 1.2.4-r2)OK: 5 MiB in 15 packages/ # apk > > > upgrade rust --repository= > > https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > --repository= > > https://dl-cdn.alpinelinux.org/alpine/v3.18/communitySegmentation > > > fault/ # apk -hSegmentation fault/ # ls /tmp/core*Segmentation fault/ > > > # cd /tmp/tmp # lsSegmentation fault > > > > i'd > > > > # cp /lib/ld-musl-armhf.so.1 /tmp > > # apk add gdb musl-dbg apk-tools-static > > > > then upgrade musl using apk.static, then debug via > > > > # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > > or analyze a core dump, you can always install more debug tools > > via apk.static and run commands using the old ld-musl-armhf.so.1 > > > > in gdb, you want to do > > > > bt > > disas $pc-40,+80 > > info reg > > info proc map > > > > as a starting point and post the results. > > > > strace output can be useful too as well as readelf -aW of ld.so > > depending on what is going on. > > > > > -- > Cody Wetzel > codyawetzel@gmail.com > (402)490-9242 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-11 17:03 ` Szabolcs Nagy @ 2024-01-11 18:19 ` Cody Wetzel 2024-01-12 18:57 ` Szabolcs Nagy 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2024-01-11 18:19 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 7543 bytes --] Sorry, I'm definitely not that well versed in linux. I received the following... / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > GNU gdb (GDB) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv7-alpine-linux-musleabihf". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ls... > (No debugging symbols found in ls) > (gdb) run > Starting program: /bin/ls -l /tmp > warning: Error disabling address space randomization: Operation not > permitted > warning: Could not trace the inferior process. > warning: ptrace: Operation not permitted > warning: Error restoring address space randomization: Operation not > permitted > During startup program exited with code 127. > Thanks! On Thu, Jan 11, 2024 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-10 09:59:18 -0600]: > > So maybe I'm not understanding how gdb works or is used. > > you have to run the process.. > > you never issued the gdb 'run' command. > > > I'm getting no > > meaningful output even though these commands should result in a > > segmentation fault. > > > > > / # gdb > > > Segmentation fault > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > <https://www.gnu.org/software/gdb/bugs/>. > > > Find the GDB manual and other documentation resources online at: > > > <http://www.gnu.org/software/gdb/documentation/>. > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from ls... > > > (No debugging symbols found in ls) > > > (gdb) > > > quit > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args cd /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > <https://www.gnu.org/software/gdb/bugs/>. > > > Find the GDB manual and other documentation resources online at: > > > <http://www.gnu.org/software/gdb/documentation/>. > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > cd: No such file or directory. > > > (gdb) > > > quit > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args apk -h /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > <https://www.gnu.org/software/gdb/bugs/>. > > > Find the GDB manual and other documentation resources online at: > > > <http://www.gnu.org/software/gdb/documentation/>. > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from apk... > > > (No debugging symbols found in apk) > > > (gdb) bt > > > No stack. > > > (gdb) disas $pc-40,+80 > > > No registers. > > > (gdb) info reg > > > The program has no registers now. > > > > > > On Thu, Jan 4, 2024 at 8:48 AM Szabolcs Nagy <nsz@port70.net> wrote: > > > > > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-03 11:20:29 -0600]: > > > > Hello musl team, > > > > > > > > I tried getting a core dump but I'm not sure if I'm doing something > > > wrong... > > > > > > > > / # cat /proc/sys/kernel/core_pattern/tmp/core-%e-%s-%u-%g-%p-%t/ # > > > > apk upgrade busybox > > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > > --repository= > https://dl-cdn.alpinelinux.org/alpine/v3.18/communityfetch > > > > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/community/armv7/APKINDEX.tar.gzfetch > > > > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gzfetch > > > > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/main/armv7/APKINDEX.tar.gzfetch > > > > > > > > https://dl-cdn.alpinelinux.org/alpine/v3.17/community/armv7/APKINDEX.tar.gz(1/3) > > > > Upgrading busybox (1.35.0-r29 -> 1.36.1-r5)Executing > > > > busybox-1.36.1-r5.post-upgrade(2/3) Upgrading busybox-binsh > > > > (1.35.0-r29 -> 1.36.1-r5)(3/3) Upgrading ssl_client (1.35.0-r29 -> > > > > 1.36.1-r5)Executing busybox-1.36.1-r5.triggerOK: 5 MiB in 15 > packages/ > > > > # apk upgrade musl > > > > --repository=https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > > --repository= > https://dl-cdn.alpinelinux.org/alpine/v3.18/community(1/1) > > > > Upgrading musl (1.2.3-r5 -> 1.2.4-r2)OK: 5 MiB in 15 packages/ # apk > > > > upgrade rust --repository= > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/main > > > > --repository= > > > https://dl-cdn.alpinelinux.org/alpine/v3.18/communitySegmentation > > > > fault/ # apk -hSegmentation fault/ # ls /tmp/core*Segmentation fault/ > > > > # cd /tmp/tmp # lsSegmentation fault > > > > > > i'd > > > > > > # cp /lib/ld-musl-armhf.so.1 /tmp > > > # apk add gdb musl-dbg apk-tools-static > > > > > > then upgrade musl using apk.static, then debug via > > > > > > # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > > > > or analyze a core dump, you can always install more debug tools > > > via apk.static and run commands using the old ld-musl-armhf.so.1 > > > > > > in gdb, you want to do > > > > > > bt > > > disas $pc-40,+80 > > > info reg > > > info proc map > > > > > > as a starting point and post the results. > > > > > > strace output can be useful too as well as readelf -aW of ld.so > > > depending on what is going on. > > > > > > > > > -- > > Cody Wetzel > > codyawetzel@gmail.com > > (402)490-9242 > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 11977 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-11 18:19 ` Cody Wetzel @ 2024-01-12 18:57 ` Szabolcs Nagy 2024-01-12 23:10 ` Cody Wetzel 0 siblings, 1 reply; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-12 18:57 UTC (permalink / raw) To: Cody Wetzel; +Cc: Natanael Copa, musl, Markus Wichmann * Cody Wetzel <codyawetzel@gmail.com> [2024-01-11 12:19:16 -0600]: > Sorry, I'm definitely not that well versed in linux. I received the > following... > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > GNU gdb (GDB) 12.1 > > Copyright (C) 2022 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from ls... > > (No debugging symbols found in ls) > > (gdb) run > > Starting program: /bin/ls -l /tmp > > warning: Error disabling address space randomization: Operation not > > permitted > > warning: Could not trace the inferior process. > > warning: ptrace: Operation not permitted > > warning: Error restoring address space randomization: Operation not > > permitted > > During startup program exited with code 127. use a container that's not restricted e.g. docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined (i found this with 2min web search) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-12 18:57 ` Szabolcs Nagy @ 2024-01-12 23:10 ` Cody Wetzel 2024-01-15 22:30 ` Szabolcs Nagy 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2024-01-12 23:10 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 3022 bytes --] I did actually find that stackoverflow post and tried spinning up a new container but the results don't provide any useful information... / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > GNU gdb (GDB) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv7-alpine-linux-musleabihf". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ls... > (No debugging symbols found in ls) > (gdb) run > Starting program: /bin/ls -l /tmp > During startup program terminated with signal SIGSEGV, Segmentation fault. > On Fri, Jan 12, 2024 at 12:57 PM Szabolcs Nagy <nsz@port70.net> wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-11 12:19:16 -0600]: > > Sorry, I'm definitely not that well versed in linux. I received the > > following... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > <https://www.gnu.org/software/gdb/bugs/>. > > > Find the GDB manual and other documentation resources online at: > > > <http://www.gnu.org/software/gdb/documentation/>. > > > > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from ls... > > > (No debugging symbols found in ls) > > > (gdb) run > > > Starting program: /bin/ls -l /tmp > > > warning: Error disabling address space randomization: Operation not > > > permitted > > > warning: Could not trace the inferior process. > > > warning: ptrace: Operation not permitted > > > warning: Error restoring address space randomization: Operation not > > > permitted > > > During startup program exited with code 127. > > use a container that's not restricted e.g. > > docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined > > (i found this with 2min web search) > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 4545 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-12 23:10 ` Cody Wetzel @ 2024-01-15 22:30 ` Szabolcs Nagy 2024-01-16 15:21 ` Cody Wetzel 0 siblings, 1 reply; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-15 22:30 UTC (permalink / raw) To: Cody Wetzel; +Cc: Natanael Copa, musl, Markus Wichmann * Cody Wetzel <codyawetzel@gmail.com> [2024-01-12 17:10:24 -0600]: > I did actually find that stackoverflow post and tried spinning up a new > container but the results don't provide any useful information... > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > GNU gdb (GDB) 12.1 > > Copyright (C) 2022 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from ls... > > (No debugging symbols found in ls) > > (gdb) run > > Starting program: /bin/ls -l /tmp > > During startup program terminated with signal SIGSEGV, Segmentation fault. > > so i looked at alpine armv7 binaries and they seem to be built with 4k page size. since the elf files are not possible to map with 32k pages, it is expected that they crash on exec in the kernel and thus you get no backtrace. i'm not sure why gdb works, unless it's an old gdb binary that's built with large pagesize support. an easy way to verify is to compare proram headers of old and new binaries like readelf -lW /tmp/ld-musl-armhf.so.1 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-15 22:30 ` Szabolcs Nagy @ 2024-01-16 15:21 ` Cody Wetzel 2024-01-16 18:29 ` Szabolcs Nagy 0 siblings, 1 reply; 26+ messages in thread From: Cody Wetzel @ 2024-01-16 15:21 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 4206 bytes --] Here is the output for the old .... > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > Elf file type is DYN (Shared object file) > Entry point 0x359cd > There are 6 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 .ARM.exidx > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > .rodata .ARM.exidx > 02 .data.rel.ro .dynamic .got .data .bss > 03 .dynamic > 04 > 05 .data.rel.ro .dynamic .got > And the new... / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > Elf file type is DYN (Shared object file) > Entry point 0x362f1 > There are 6 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 .ARM.exidx > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > .rodata .ARM.exidx > 02 .data.rel.ro .dynamic .got .data .bss > 03 .dynamic > 04 > 05 .data.rel.ro .dynamic .got I hope that helps. Thanks! Cody On Mon, Jan 15, 2024 at 4:30 PM Szabolcs Nagy <nsz@port70.net> wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-12 17:10:24 -0600]: > > I did actually find that stackoverflow post and tried spinning up a new > > container but the results don't provide any useful information... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > <https://www.gnu.org/software/gdb/bugs/>. > > > Find the GDB manual and other documentation resources online at: > > > <http://www.gnu.org/software/gdb/documentation/>. > > > > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from ls... > > > (No debugging symbols found in ls) > > > (gdb) run > > > Starting program: /bin/ls -l /tmp > > > During startup program terminated with signal SIGSEGV, Segmentation > fault. > > > > > so i looked at alpine armv7 binaries and they seem to be built with > 4k page size. > > since the elf files are not possible to map with 32k pages, it is > expected that they crash on exec in the kernel and thus you get no > backtrace. > > i'm not sure why gdb works, unless it's an old gdb binary that's built > with large pagesize support. > > an easy way to verify is to compare proram headers of old and new > binaries like > > readelf -lW /tmp/ld-musl-armhf.so.1 > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 5979 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-16 15:21 ` Cody Wetzel @ 2024-01-16 18:29 ` Szabolcs Nagy 2024-01-16 18:53 ` Cody Wetzel 2024-01-16 20:45 ` Rich Felker 0 siblings, 2 replies; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-16 18:29 UTC (permalink / raw) To: Cody Wetzel; +Cc: Natanael Copa, musl, Markus Wichmann * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > Here is the output for the old > .... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > Elf file type is DYN (Shared object file) > > Entry point 0x359cd > > There are 6 program headers, starting at offset 52 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 this load segment is 64k aligned. > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > Section to Segment mapping: > > Segment Sections... > > 00 .ARM.exidx > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > .rodata .ARM.exidx > > 02 .data.rel.ro .dynamic .got .data .bss > > 03 .dynamic > > 04 > > 05 .data.rel.ro .dynamic .got > > > > And the new... > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > Elf file type is DYN (Shared object file) > > Entry point 0x362f1 > > There are 6 program headers, starting at offset 52 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 this load segment is 4k aligned and offset vs addr is not congruent modulo 64k, or 32k, so won't work on systems with such page size. > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > Section to Segment mapping: > > Segment Sections... > > 00 .ARM.exidx > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > .rodata .ARM.exidx > > 02 .data.rel.ro .dynamic .got .data .bss > > 03 .dynamic > > 04 > > 05 .data.rel.ro .dynamic .got > > > I hope that helps. yes, this is a linking issue, not musl libc. alpine linux links binaries for 4k pagesize only. arm linkers were updated at some point to create binaries supporting up to 64k pagesize. i suspect some ppl ran into issues in practice and decided the larger binaries are not worth it, if they dont work reliably and forced 4k page size at link time. you have to raise an issue with alpine linux, if you think 32k oage size is useful and reliably supportable. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-16 18:29 ` Szabolcs Nagy @ 2024-01-16 18:53 ` Cody Wetzel 2024-01-16 20:45 ` Rich Felker 1 sibling, 0 replies; 26+ messages in thread From: Cody Wetzel @ 2024-01-16 18:53 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann [-- Attachment #1: Type: text/plain, Size: 3419 bytes --] Thank you so much for pointing me in the right direction! Cody On Tue, Jan 16, 2024 at 12:29 PM Szabolcs Nagy <nsz@port70.net> wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > > Here is the output for the old > > .... > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW > /tmp/ld-musl-armhf.so.1 > > > > > > Elf file type is DYN (Shared object file) > > > Entry point 0x359cd > > > There are 6 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg > Align > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E > 0x10000 > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW > 0x10000 > > this load segment is 64k aligned. > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW > 0x10 > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > .rodata .ARM.exidx > > > 02 .data.rel.ro .dynamic .got .data .bss > > > 03 .dynamic > > > 04 > > > 05 .data.rel.ro .dynamic .got > > > > > > > And the new... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > Elf file type is DYN (Shared object file) > > > Entry point 0x362f1 > > > There are 6 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg > Align > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E > 0x1000 > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW > 0x1000 > > this load segment is 4k aligned and offset vs addr is not congruent > modulo 64k, or 32k, so won't work on systems with such page size. > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW > 0x10 > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > .rodata .ARM.exidx > > > 02 .data.rel.ro .dynamic .got .data .bss > > > 03 .dynamic > > > 04 > > > 05 .data.rel.ro .dynamic .got > > > > > > I hope that helps. > > yes, this is a linking issue, not musl libc. > > alpine linux links binaries for 4k pagesize only. > > arm linkers were updated at some point to create binaries supporting > up to 64k pagesize. i suspect some ppl ran into issues in practice > and decided the larger binaries are not worth it, if they dont work > reliably and forced 4k page size at link time. > > you have to raise an issue with alpine linux, if you think 32k > oage size is useful and reliably supportable. > > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242 [-- Attachment #2: Type: text/html, Size: 4874 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-16 18:29 ` Szabolcs Nagy 2024-01-16 18:53 ` Cody Wetzel @ 2024-01-16 20:45 ` Rich Felker 2024-01-30 10:43 ` Szabolcs Nagy 1 sibling, 1 reply; 26+ messages in thread From: Rich Felker @ 2024-01-16 20:45 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann On Tue, Jan 16, 2024 at 07:29:18PM +0100, Szabolcs Nagy wrote: > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > > Here is the output for the old > > .... > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > > > Elf file type is DYN (Shared object file) > > > Entry point 0x359cd > > > There are 6 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > > this load segment is 64k aligned. > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > .rodata .ARM.exidx > > > 02 .data.rel.ro .dynamic .got .data .bss > > > 03 .dynamic > > > 04 > > > 05 .data.rel.ro .dynamic .got > > > > > > > And the new... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > Elf file type is DYN (Shared object file) > > > Entry point 0x362f1 > > > There are 6 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > > this load segment is 4k aligned and offset vs addr is not congruent > modulo 64k, or 32k, so won't work on systems with such page size. > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > .rodata .ARM.exidx > > > 02 .data.rel.ro .dynamic .got .data .bss > > > 03 .dynamic > > > 04 > > > 05 .data.rel.ro .dynamic .got > > > > > > I hope that helps. > > yes, this is a linking issue, not musl libc. > > alpine linux links binaries for 4k pagesize only. > > arm linkers were updated at some point to create binaries supporting > up to 64k pagesize. i suspect some ppl ran into issues in practice > and decided the larger binaries are not worth it, if they dont work > reliably and forced 4k page size at link time. > > you have to raise an issue with alpine linux, if you think 32k > oage size is useful and reliably supportable. Are they using -Wl,-z,separate-code? That incurs a large binary-size-on-disk penalty when supporting oversized pages, and IIRC something was done to make the linker default to not supporting oversized pages when that's used. It might be the reason, if arm linking is normally expected to use a larger max pagesize. Rich ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-16 20:45 ` Rich Felker @ 2024-01-30 10:43 ` Szabolcs Nagy 2024-01-30 15:37 ` Rich Felker 0 siblings, 1 reply; 26+ messages in thread From: Szabolcs Nagy @ 2024-01-30 10:43 UTC (permalink / raw) To: Rich Felker; +Cc: Cody Wetzel, Natanael Copa, musl, Markus Wichmann * Rich Felker <dalias@libc.org> [2024-01-16 15:45:52 -0500]: > On Tue, Jan 16, 2024 at 07:29:18PM +0100, Szabolcs Nagy wrote: > > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > > > Here is the output for the old > > > .... > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > > > > > Elf file type is DYN (Shared object file) > > > > Entry point 0x359cd > > > > There are 6 program headers, starting at offset 52 > > > > > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > > > > this load segment is 64k aligned. > > > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > > > Section to Segment mapping: > > > > Segment Sections... > > > > 00 .ARM.exidx > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > .rodata .ARM.exidx > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > 03 .dynamic > > > > 04 > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > And the new... > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > > > Elf file type is DYN (Shared object file) > > > > Entry point 0x362f1 > > > > There are 6 program headers, starting at offset 52 > > > > > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > > > > this load segment is 4k aligned and offset vs addr is not congruent > > modulo 64k, or 32k, so won't work on systems with such page size. > > > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > > > Section to Segment mapping: > > > > Segment Sections... > > > > 00 .ARM.exidx > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > .rodata .ARM.exidx > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > 03 .dynamic > > > > 04 > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > I hope that helps. > > > > yes, this is a linking issue, not musl libc. > > > > alpine linux links binaries for 4k pagesize only. > > > > arm linkers were updated at some point to create binaries supporting > > up to 64k pagesize. i suspect some ppl ran into issues in practice > > and decided the larger binaries are not worth it, if they dont work > > reliably and forced 4k page size at link time. > > > > you have to raise an issue with alpine linux, if you think 32k > > oage size is useful and reliably supportable. > > Are they using -Wl,-z,separate-code? That incurs a large > binary-size-on-disk penalty when supporting oversized pages, and IIRC > something was done to make the linker default to not supporting > oversized pages when that's used. It might be the reason, if arm > linking is normally expected to use a larger max pagesize. i looked at this now, turns out they just changed the pagesize back to 4k (i missed this change): https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2024-01-30 10:43 ` Szabolcs Nagy @ 2024-01-30 15:37 ` Rich Felker 2024-01-30 20:17 ` [musl] Fixing ELF loader for systems with oversized pages [was: Re: [musl] Segmentation fault musl 1.2.4] Rich Felker 0 siblings, 1 reply; 26+ messages in thread From: Rich Felker @ 2024-01-30 15:37 UTC (permalink / raw) To: Cody Wetzel, Natanael Copa, musl, Markus Wichmann On Tue, Jan 30, 2024 at 11:43:38AM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@libc.org> [2024-01-16 15:45:52 -0500]: > > > On Tue, Jan 16, 2024 at 07:29:18PM +0100, Szabolcs Nagy wrote: > > > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > > > > Here is the output for the old > > > > .... > > > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > > > > > > > Elf file type is DYN (Shared object file) > > > > > Entry point 0x359cd > > > > > There are 6 program headers, starting at offset 52 > > > > > > > > > > Program Headers: > > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > > > > > > this load segment is 64k aligned. > > > > > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > > > > > Section to Segment mapping: > > > > > Segment Sections... > > > > > 00 .ARM.exidx > > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > > .rodata .ARM.exidx > > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > > 03 .dynamic > > > > > 04 > > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > > > > And the new... > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > > > > > Elf file type is DYN (Shared object file) > > > > > Entry point 0x362f1 > > > > > There are 6 program headers, starting at offset 52 > > > > > > > > > > Program Headers: > > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > > > > > > this load segment is 4k aligned and offset vs addr is not congruent > > > modulo 64k, or 32k, so won't work on systems with such page size. > > > > > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > > > > > Section to Segment mapping: > > > > > Segment Sections... > > > > > 00 .ARM.exidx > > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > > .rodata .ARM.exidx > > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > > 03 .dynamic > > > > > 04 > > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > > > I hope that helps. > > > > > > yes, this is a linking issue, not musl libc. > > > > > > alpine linux links binaries for 4k pagesize only. > > > > > > arm linkers were updated at some point to create binaries supporting > > > up to 64k pagesize. i suspect some ppl ran into issues in practice > > > and decided the larger binaries are not worth it, if they dont work > > > reliably and forced 4k page size at link time. > > > > > > you have to raise an issue with alpine linux, if you think 32k > > > oage size is useful and reliably supportable. > > > > Are they using -Wl,-z,separate-code? That incurs a large > > binary-size-on-disk penalty when supporting oversized pages, and IIRC > > something was done to make the linker default to not supporting > > oversized pages when that's used. It might be the reason, if arm > > linking is normally expected to use a larger max pagesize. > > i looked at this now, turns out they just changed the > pagesize back to 4k (i missed this change): > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 This doesn't help immediately, but a major ingredient to fix this situation would be getting the kernel to stop doing the wrong thing. Right now, it's ignoring the fact that the ELF program header constraints are incompatible with mmap given the oversized system pagesize, and just incorrectly mapping the executable and trying to run it anyway, whereby it blows up. The right thing to do would be either to fail with ENOEXEC in this case, or when mmap with the required offset constraint fails, falling back to making an anonymous map and copying the whole content of the loadable segment into that (no COW sharing). The latter is really not all that bad for got/data/etc. mappings which you expect will be dirty (modified) anyway. BTW the former choice (ENOEXEC) would allow doing the latter in userspace with a binfmt_misc loader. Rich ^ permalink raw reply [flat|nested] 26+ messages in thread
* [musl] Fixing ELF loader for systems with oversized pages [was: Re: [musl] Segmentation fault musl 1.2.4] 2024-01-30 15:37 ` Rich Felker @ 2024-01-30 20:17 ` Rich Felker 0 siblings, 0 replies; 26+ messages in thread From: Rich Felker @ 2024-01-30 20:17 UTC (permalink / raw) To: musl; +Cc: linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 5368 bytes --] On Tue, Jan 30, 2024 at 10:37:30AM -0500, Rich Felker wrote: > On Tue, Jan 30, 2024 at 11:43:38AM +0100, Szabolcs Nagy wrote: > > * Rich Felker <dalias@libc.org> [2024-01-16 15:45:52 -0500]: > > > > > On Tue, Jan 16, 2024 at 07:29:18PM +0100, Szabolcs Nagy wrote: > > > > * Cody Wetzel <codyawetzel@gmail.com> [2024-01-16 09:21:05 -0600]: > > > > > Here is the output for the old > > > > > .... > > > > > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > > > > > > > > > Elf file type is DYN (Shared object file) > > > > > > Entry point 0x359cd > > > > > > There are 6 program headers, starting at offset 52 > > > > > > > > > > > > Program Headers: > > > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > > > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > > > > > > > > this load segment is 64k aligned. > > > > > > > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > > > > > > > Section to Segment mapping: > > > > > > Segment Sections... > > > > > > 00 .ARM.exidx > > > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > > > .rodata .ARM.exidx > > > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > > > 03 .dynamic > > > > > > 04 > > > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > > > > > > > And the new... > > > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > > > > > > > Elf file type is DYN (Shared object file) > > > > > > Entry point 0x362f1 > > > > > > There are 6 program headers, starting at offset 52 > > > > > > > > > > > > Program Headers: > > > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > > > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > > > > > > > > this load segment is 4k aligned and offset vs addr is not congruent > > > > modulo 64k, or 32k, so won't work on systems with such page size. > > > > > > > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > > > > > > > Section to Segment mapping: > > > > > > Segment Sections... > > > > > > 00 .ARM.exidx > > > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > > > .rodata .ARM.exidx > > > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > > > 03 .dynamic > > > > > > 04 > > > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > > > > > > I hope that helps. > > > > > > > > yes, this is a linking issue, not musl libc. > > > > > > > > alpine linux links binaries for 4k pagesize only. > > > > > > > > arm linkers were updated at some point to create binaries supporting > > > > up to 64k pagesize. i suspect some ppl ran into issues in practice > > > > and decided the larger binaries are not worth it, if they dont work > > > > reliably and forced 4k page size at link time. > > > > > > > > you have to raise an issue with alpine linux, if you think 32k > > > > oage size is useful and reliably supportable. > > > > > > Are they using -Wl,-z,separate-code? That incurs a large > > > binary-size-on-disk penalty when supporting oversized pages, and IIRC > > > something was done to make the linker default to not supporting > > > oversized pages when that's used. It might be the reason, if arm > > > linking is normally expected to use a larger max pagesize. > > > > i looked at this now, turns out they just changed the > > pagesize back to 4k (i missed this change): > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 > > This doesn't help immediately, but a major ingredient to fix this > situation would be getting the kernel to stop doing the wrong thing. > Right now, it's ignoring the fact that the ELF program header > constraints are incompatible with mmap given the oversized system > pagesize, and just incorrectly mapping the executable and trying to > run it anyway, whereby it blows up. > > The right thing to do would be either to fail with ENOEXEC in this > case, or when mmap with the required offset constraint fails, falling > back to making an anonymous map and copying the whole content of the > loadable segment into that (no COW sharing). The latter is really not > all that bad for got/data/etc. mappings which you expect will be dirty > (modified) anyway. > > BTW the former choice (ENOEXEC) would allow doing the latter in > userspace with a binfmt_misc loader. Completely untested draft patch showing the concept is attached. Rich [-- Attachment #2: fix_elf_loader_with_oversized_pages.diff --] [-- Type: text/plain, Size: 1034 bytes --] diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index f8c7f26f1fbb..45c50f379377 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -861,6 +861,12 @@ static int load_elf_binary(struct linux_binprm *bprm) if (!elf_phdata) goto out; + elf_ppnt = elf_phdata; + for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++) { + if (elf_ppnt->p_type != PT_LOAD) continue; + if (ELF_PAGEOFFSET(elf_ppnt->p_vaddr - elf_ppnt->p_offset)) + goto out; + } elf_ppnt = elf_phdata; for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++) { char *elf_interpreter; @@ -962,6 +968,13 @@ static int load_elf_binary(struct linux_binprm *bprm) if (!interp_elf_phdata) goto out_free_dentry; + elf_ppnt = interp_elf_phdata; + for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++) { + if (elf_ppnt->p_type != PT_LOAD) continue; + if (ELF_PAGEOFFSET(elf_ppnt->p_vaddr - elf_ppnt->p_offset)) + goto out_free_dentry; + } + /* Pass PT_LOPROC..PT_HIPROC headers to arch code */ elf_property_phdata = NULL; elf_ppnt = interp_elf_phdata; ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-20 21:53 [musl] Segmentation fault musl 1.2.4 Cody Wetzel 2023-12-21 3:38 ` Rich Felker 2023-12-21 7:57 ` Markus Wichmann @ 2023-12-22 2:20 ` Jeffrey Walton 2023-12-22 2:22 ` Jeffrey Walton 2 siblings, 1 reply; 26+ messages in thread From: Jeffrey Walton @ 2023-12-22 2:20 UTC (permalink / raw) To: musl On Wed, Dec 20, 2023 at 4:54 PM Cody Wetzel <codyawetzel@gmail.com> wrote: > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP updated the pagesize to 32k and I believe musl isn't handling it gracefully. musl 1.2.3 does not have this problem. > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices Related, Apple M1's use a 32k page size. It is baked into the MMU. 32k memory pages has caused a fair amount of trouble for Asashi Linux, especially for some userland programs. See<https://github.com/AsahiLinux/docs/wiki/Broken-Software>. Jeff ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Segmentation fault musl 1.2.4 2023-12-22 2:20 ` [musl] Segmentation fault musl 1.2.4 Jeffrey Walton @ 2023-12-22 2:22 ` Jeffrey Walton 0 siblings, 0 replies; 26+ messages in thread From: Jeffrey Walton @ 2023-12-22 2:22 UTC (permalink / raw) To: musl On Thu, Dec 21, 2023 at 9:20 PM Jeffrey Walton <noloader@gmail.com> wrote: > > On Wed, Dec 20, 2023 at 4:54 PM Cody Wetzel <codyawetzel@gmail.com> wrote: > > > > I am running into a segmentation fault on musl 1.2.4 on my QNAP NAS. QNAP updated the pagesize to 32k and I believe musl isn't handling it gracefully. musl 1.2.3 does not have this problem. > > > > https://www.qnap.com/da-dk/how-to/faq/article/why-do-the-installed-third-party-containers-not-run-successfully-on-specific-32-bit-arm-devices > > Related, Apple M1's use a 32k page size. It is baked into the MMU. 32k > memory pages has caused a fair amount of trouble for Asashi Linux, > especially for some userland programs. > See<https://github.com/AsahiLinux/docs/wiki/Broken-Software>. My bad, s/32k/16k. Jeff ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2024-01-30 20:17 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-20 21:53 [musl] Segmentation fault musl 1.2.4 Cody Wetzel 2023-12-21 3:38 ` Rich Felker 2023-12-21 4:15 ` Rich Felker 2023-12-21 7:57 ` Markus Wichmann 2023-12-21 18:39 ` Cody Wetzel 2023-12-21 21:25 ` Natanael Copa 2023-12-21 21:57 ` Cody Wetzel 2024-01-03 17:20 ` Cody Wetzel 2024-01-03 17:26 ` Leah Neukirchen 2024-01-03 18:00 ` Cody Wetzel 2024-01-04 14:48 ` Szabolcs Nagy 2024-01-10 15:59 ` Cody Wetzel 2024-01-11 17:03 ` Szabolcs Nagy 2024-01-11 18:19 ` Cody Wetzel 2024-01-12 18:57 ` Szabolcs Nagy 2024-01-12 23:10 ` Cody Wetzel 2024-01-15 22:30 ` Szabolcs Nagy 2024-01-16 15:21 ` Cody Wetzel 2024-01-16 18:29 ` Szabolcs Nagy 2024-01-16 18:53 ` Cody Wetzel 2024-01-16 20:45 ` Rich Felker 2024-01-30 10:43 ` Szabolcs Nagy 2024-01-30 15:37 ` Rich Felker 2024-01-30 20:17 ` [musl] Fixing ELF loader for systems with oversized pages [was: Re: [musl] Segmentation fault musl 1.2.4] Rich Felker 2023-12-22 2:20 ` [musl] Segmentation fault musl 1.2.4 Jeffrey Walton 2023-12-22 2:22 ` Jeffrey Walton
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).