Re: aarch64: sysutils/cpu-x@ncurses got SIGSEGV during its initial print_activecore
Date: Sun, 03 Dec 2023 07:26:04 UTC
On Dec 2, 2023, at 23:16, Mark Millard <marklmi@yahoo.com> wrote: > Note: This is from my own poudriere-devel based build of: > sysutils/cpu-x@ncurses > > gdb reports from the cpu-x.core that was generated: > > Core was generated by `cpu-x'. > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 0x000000002acc3a04 in __strtok_r (s=0x1 <error: Cannot access memory at address 0x1>, delim=delim@entry=0x203f9e "]", last=<optimized out>) at /usr/main-src/lib/libc/string/strtok.c:60 > 60 c = *s++; > (gdb) bt > #0 0x000000002acc3a04 in __strtok_r (s=0x1 <error: Cannot access memory at address 0x1>, delim=delim@entry=0x203f9e "]", last=<optimized out>) at /usr/main-src/lib/libc/string/strtok.c:60 > #1 strtok (s=<optimized out>, delim=delim@entry=0x203f9e "]") at /usr/main-src/lib/libc/string/strtok.c:98 > #2 0x00000000002271bc in common_sighandler (signum=11, need_stop=true) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:685 > #3 0x0000000027df981c in handle_signal (actp=actp@entry=0x24b520e0, sig=sig@entry=11, info=info@entry=0x24b52150, ucp=ucp@entry=0x24b521a0) at /usr/main-src/lib/libthr/thread/thr_sig.c:301 > #4 0x0000000027df8eb8 in thr_sighandler (sig=11, info=0x24b52150, _ucp=0x24b521a0) at /usr/main-src/lib/libthr/thread/thr_sig.c:244 > #5 <signal handler called> > #6 0x000000000022e850 in print_activecore (win=0x26de3f714390, data=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:595 > #7 ntab_cpu (win=0x26de3f714390, info=..., data=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:664 > #8 0x000000000022d09c in start_tui_ncurses (data=data@entry=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:117 > #9 0x0000000000226ba8 in main (argc=<optimized out>, argv=<optimized out>) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:858 > > # ldd -a `which cpu-x` > /usr/local/bin/cpu-x: > libm.so.5 => /lib/libm.so.5 (0x516dbd5000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x516f604000) > libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x516ff9c000) > libncursesw.so.9 => /lib/libncursesw.so.9 (0x5170cc2000) > libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) > libcpuid.so.16 => /usr/local/lib/libcpuid.so.16 (0x5172ab8000) > libpci.so.3 => /usr/local/lib/libpci.so.3 (0x517203c000) > libstatgrab.so.10 => /usr/local/lib/libstatgrab.so.10 (0x5172de8000) > libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libm.so.5: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libintl.so.8: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libthr.so.3: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/lib/libexecinfo.so.1: > libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x51750e8000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libncursesw.so.9: > libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libtinfow.so.9: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libcpuid.so.16: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libpci.so.3: > libz.so.6 => /lib/libz.so.6 (0x5176aee000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libstatgrab.so.10: > libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) > libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libdevstat.so.7: > libkvm.so.7 => /lib/libkvm.so.7 (0x5177a46000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libelf.so.2: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libgcc_s.so.1: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libz.so.6: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libkvm.so.7: > libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > > > For reference: > > # uname -apKU > FreeBSD CA72-16Gp-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #121 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 17:55:51 PST 2023 root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1500005 1500005 > > # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ > 6ec8e3450b29 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/sdts++: Mark DEPRECATED > Author: Muhammad Moinur Rahman <bofh@FreeBSD.org> > Commit: Muhammad Moinur Rahman <bofh@FreeBSD.org> > CommitDate: 2023-10-21 19:01:38 +0000 > branch: main > merge-base: 6ec8e3450b29462a590d09fb0b07ed214d456bd5 > merge-base: CommitDate: 2023-10-21 19:01:38 +0000 > n637598 (--first-parent --count for merge-base) > Hmm. On thinking about it, the output: # cpu-x CPU-X:core.c:301: failed to call libcpuid (CPUID instruction is not supported) CPU-X:core.c:1478: failed to find chipset vendor and model CPU-X:core.c:1480: failed to find graphic card vendor and model CPU-X:core.c:2260: failed to retrieve CPU temperature (fallback mode) that also occured may be more of an indication that aarch64 is not actually supported by the infrastructure used. The Makefile should possibly block doing aarch64 builds that will not work. Likely more than aarch64 would have that status. I'll also note: headless, so no "graphic card vendor and model" to find. === Mark Millard marklmi at yahoo.com