Hi all,
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
I know F-36 is getting EOLed soon, but there might be a toolchain issue that might be worth looking at. Please see https://bugzilla.redhat.com/show_bug.cgi?id=2181826 for more details.
Thanks,
Dan
On 04-04-2023 16:48, Dan Horák wrote:
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
For what it's worth, I tried it on F35, util-linux-core-2.37.4-1.fc35.armv7hl, and the command completed successfully. This is on a Pi 3B with 1 GB of RAM.
For testing on F36 I would need to upgrade or use a different device. Let me know if you'd like me to.
-- Sandro
On Wed, 5 Apr 2023 16:07:33 +0200 Sandro lists@penguinpee.nl wrote:
On 04-04-2023 16:48, Dan Horák wrote:
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
For what it's worth, I tried it on F35, util-linux-core-2.37.4-1.fc35.armv7hl, and the command completed successfully. This is on a Pi 3B with 1 GB of RAM.
thanks for the check
For testing on F36 I would need to upgrade or use a different device. Let me know if you'd like me to.
yes, verifying on F-36 would be useful
Dan
Le mar. 4 avr. 2023 à 16:48, Dan Horák dan@danny.cz a écrit :
Hi all,
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
I know F-36 is getting EOLed soon, but there might be a toolchain issue that might be worth looking at. Please see https://bugzilla.redhat.com/show_bug.cgi?id=2181826 for more details.
It segfaults also with me on trimslice. (Tegra20 SoC).
Le ven. 7 avr. 2023 à 18:44, Nicolas Chauvet kwizart@gmail.com a écrit :
Le mar. 4 avr. 2023 à 16:48, Dan Horák dan@danny.cz a écrit :
Hi all,
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
I know F-36 is getting EOLed soon, but there might be a toolchain issue that might be worth looking at. Please see https://bugzilla.redhat.com/show_bug.cgi?id=2181826 for more details.
It segfaults also with me on trimslice. (Tegra20 SoC).
When run under valgrind, it shows:
# LANG=C valgrind /usr/bin/hardlink -n -c -vvv . ==669== Memcheck, a memory error detector ==669== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==669== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==669== Command: /usr/bin/hardlink -n -c -vvv . ==669== Scanning [device/inode/links]: ==669== Invalid read of size 1 ==669== at 0x486C0B8: strlen (vg_replace_strmem.c:495) ==669== by 0x491C947: __vfprintf_internal (vfprintf-internal.c:1517) ==669== by 0x10A71B: UnknownInlinedFun (stdio2.h:135) ==669== by 0x10A71B: jlog (hardlink.c:230) ==669== by 0x10D4E3: UnknownInlinedFun (hardlink.c:814) ==669== by 0x10D4E3: inserter (hardlink.c:783) ==669== by 0x49A72AB: process_entry.constprop.0 (ftw.c:472) ==669== by 0x49A777B: ftw_dir (ftw.c:551) ==669== by 0x49A80D3: ftw_startup (ftw.c:771) ==669== by 0x49A820B: nftw64@@GLIBC_2.4 (ftw.c:844) ==669== by 0x109BF7: main (hardlink.c:1374) ==669== Address 0x936 is not stack'd, malloc'd or (recently) free'd ==669== ==669== ==669== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==669== Access not within mapped region at address 0x936 ==669== at 0x486C0B8: strlen (vg_replace_strmem.c:495) ==669== by 0x491C947: __vfprintf_internal (vfprintf-internal.c:1517) ==669== by 0x10A71B: UnknownInlinedFun (stdio2.h:135) ==669== by 0x10A71B: jlog (hardlink.c:230) ==669== by 0x10D4E3: UnknownInlinedFun (hardlink.c:814) ==669== by 0x10D4E3: inserter (hardlink.c:783) ==669== by 0x49A72AB: process_entry.constprop.0 (ftw.c:472) ==669== by 0x49A777B: ftw_dir (ftw.c:551) ==669== by 0x49A80D3: ftw_startup (ftw.c:771) ==669== by 0x49A820B: nftw64@@GLIBC_2.4 (ftw.c:844) ==669== by 0x109BF7: main (hardlink.c:1374) ==669== If you believe this happened as a result of a stack ==669== overflow in your program's main thread (unlikely but ==669== possible), you can try to increase the size of the ==669== main thread stack using the --main-stacksize= flag. ==669== The main thread stack size used in this run was 8388608. ==669== ==669== HEAP SUMMARY: ==669== in use at exit: 38,040 bytes in 6 blocks ==669== total heap usage: 6 allocs, 0 frees, 38,040 bytes allocated ==669== ==669== LEAK SUMMARY: ==669== definitely lost: 0 bytes in 0 blocks ==669== indirectly lost: 0 bytes in 0 blocks ==669== possibly lost: 0 bytes in 0 blocks ==669== still reachable: 38,040 bytes in 6 blocks ==669== suppressed: 0 bytes in 0 blocks ==669== Rerun with --leak-check=full to see details of leaked memory ==669== ==669== For lists of detected and suppressed errors, rerun with: -s ==669== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Erreur de segmentation (core dumped)
On Fri, 7 Apr 2023 18:44:35 +0200 Nicolas Chauvet kwizart@gmail.com wrote:
Le mar. 4 avr. 2023 à 16:48, Dan Horák dan@danny.cz a écrit :
Hi all,
is anyone here still running an armv7 hw with F-36? Could you check if /usr/bin/hardlink -n -c -vvv . in some directory with some files segfaults for you?
I know F-36 is getting EOLed soon, but there might be a toolchain issue that might be worth looking at. Please see https://bugzilla.redhat.com/show_bug.cgi?id=2181826 for more details.
It segfaults also with me on trimslice. (Tegra20 SoC).
thanks for the confirmation
Dan
-
Dan Horák -
Nicolas Chauvet -
Sandro