Le ven. 7 avr. 2023 à 18:44, Nicolas Chauvet <kwizart@xxxxxxxxx> a écrit : > > Le mar. 4 avr. 2023 à 16:48, Dan Horák <dan@xxxxxxxx> 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) _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
