* Dan Horák: > On Sun, 27 Jul 2025 21:34:12 +0200 > Sandro Mani <manisan...@gmail.com> wrote: > >> Hi >> >> scotch is currently FTBFS on ppc64le (affects the current 7.0.7, the >> previous 7.0.6, as well as the new 7.0.8 release), failing with [1] >> >> gmake[2]: *** [src/libscotch/CMakeFiles/ptscotchf_h.dir/build.make:77: >> src/include/ptscotchf.h] Illegal instruction (core dumped) >> >> 7.0.6 previously successfully built with gcc-0:15.0.1-0.3.fc42.1.ppc64le and >> now fails with gcc-0:15.1.1-5.fc43.1.ppc64le, so this looks like a gcc >> regression. >> >> Being this on ppc64le and having no access to such a machine, how can I >> debug this? > > you have access to a system from > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > and it can be reproduced there. But it needs the Power10 system (same > as current koji builders), not the Power9 (pre-DC-migration koji > builders, it builds there OK). > > ppc64le-redhat-linux-gnu-openmpi/src/libscotch/ptdummysizes is the > crashing binary ... > > and running it under gdb gives > > ... > Program received signal SIGILL, Illegal instruction. > 0x00007ffff774e404 in sbrk () from /lib64/glibc-hwcaps/power10/libc.so.6 > (gdb) where > #0 0x00007ffff774e404 in sbrk () from /lib64/glibc-hwcaps/power10/libc.so.6 > #1 0x00007ffff787b38c in ucm_fire_mmap_events_internal () from > /lib64/libucm.so.0 > #2 0x00007ffff787bd88 in ucm_mmap_test_events_nolock () from > /lib64/libucm.so.0 > #3 0x00007ffff78818b8 in ucm_mmap_install () from /lib64/libucm.so.0 > #4 0x00007ffff7881b30 in ucm_mmap_init () from /lib64/libucm.so.0 > #5 0x00007ffff7881c2c in ucm_library_init () from /lib64/libucm.so.0 > #6 0x00007ffff7881cbc in ucm_set_global_opts () from /lib64/libucm.so.0 > #7 0x00007ffff725745c in ucs_init_ucm_opts () from /lib64/libucs.so.0 > #8 0x00007ffff7243fb0 in ucs_init () from /lib64/libucs.so.0 > #9 0x00007ffff7f989bc in call_init (l=<optimized out>, argc=1, > argv=0x7fffffffece8, env=0x7fffffffecf8) at dl-init.c:74 > #10 _dl_init (main_map=0x7ffff7ff12f0, argc=1, argv=0x7fffffffece8, > env=0x7fffffffecf8) at dl-init.c:121 > #11 0x00007ffff7fc3eb8 in _dl_start_user () from /lib64/ld64.so.2
The location of the crash: Dump of assembler code for function __GI___sbrk: 0x00007ffff774e400 <+0>: d1 ff 21 f8 stdu r1,-48(r1) => 0x00007ffff774e404 <+4>: 0e 00 10 06 .long 0x610000e 0x00007ffff774e408 <+8>: 00 00 60 3d lis r11,0 0x00007ffff774e40c <+12>: ff 7f 6b 61 ori r11,r11,32767 0x00007ffff774e410 <+16>: c7 07 6b 79 sldi. r11,r11,32 0x00007ffff774e414 <+20>: 87 f7 6b 65 oris r11,r11,63367 0x00007ffff774e418 <+24>: b8 9e 6b 61 ori r11,r11,40632 0x00007ffff774e41c <+28>: a6 03 69 7d mtctr r11 0x00007ffff774e420 <+32>: 20 04 80 4e bctr 0x00007ffff774e424 <+36>: 40 00 01 f8 std r0,64(r1) 0x00007ffff774e428 <+40>: 99 61 ff 4b bl 0x7ffff77445c0 <__brk> This was patched by the ucx library. The original looks like this: 000000000014e400 <__sbrk>: 14e400: d1 ff 21 f8 stdu r1,-48(r1) 14e404: 0e 00 10 06 plbz r9,961781 # 2390f9 <__libc_initial> 14e408: f5 ac 20 89 14e40c: 78 1b 62 7c mr r2,r3 14e410: 00 00 09 2c cmpwi r9,0 14e414: 4c 00 82 40 bne 14e460 <__sbrk+0x60> 14e418: 00 00 23 2c cmpdi r3,0 14e41c: b0 00 82 40 bne 14e4cc <__sbrk+0xcc> 14e420: a6 02 08 7c mflr r0 14e424: 40 00 01 f8 std r0,64(r1) 14e428: 99 61 ff 4b bl 1445c0 <brk> So there was a 64-bit instruction bundle at the patched offset, and that may have been the reason why ucx failed to patch properly. I would very much prefer if there weren't any libraries like ucx in Fedora that patch glibc merely because you link against them. It's fine to do this for debugging tools, but as part of regular execution, it risks too much breakage. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
