[fedora-arm] Re: hardlink segfaults on armv7 in F-36

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)
_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue