Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context.
- Reply: Mark Millard via freebsd-current : "Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context."
- In reply to: Tomoaki AOKI : "Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 21 Oct 2021 18:53:05 UTC
On 2021-Oct-21, at 08:27, Tomoaki AOKI <junchoon at dec.sakura.ne.jp> wrote: > On Thu, 21 Oct 2021 07:40:36 -0700 > Mark Millard via freebsd-current <freebsd-current@freebsd.org> wrote: > >> >> >> On 2021-Oct-21, at 06:14, Gary Jennejohn <gljennjohn@gmail.com> wrote: >> >>> On Thu, 21 Oct 2021 01:34:47 -0700 >>> Mark Millard via freebsd-current <freebsd-current@freebsd.org> wrote: >>> >>>> I get the following crash (amd64 example shown), as reported >>>> via gdb afterwards. (devel/llvm13 is just an example context.) >>>> >>>> gdb `which dialog4ports` devel/llvm13/dialog4ports.core >>>> . . . >>>> Core was generated by `/usr/local/bin/dialog4ports'. >>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>> Address not mapped to object. >>>> #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 <__xlocale_global_locale>, fmt0=0x201f64 "\"%s\"", ap=ap@entry=0x7fffffffcf00) at /usr/main-src/lib/libc/stdio/vfprintf.c:281 >>>> 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && >>>> (gdb) bt >>>> #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 <__xlocale_global_locale>, fmt0=0x201f64 "\"%s\"", ap=ap@entry=0x7fffffffcf00) at /usr/main-src/lib/libc/stdio/vfprintf.c:281 >>>> #1 0x0000000800409283 in fprintf (fp=0x800411660 <__stdio_cancel_cleanup>, fmt=0x7fffffffcdd0 "0\317\377\377\377\177") at /usr/main-src/lib/libc/stdio/fprintf.c:57 >>>> #2 0x000000000020399d in main (argc=<optimized out>, argv=<optimized out>) at dialog4ports.c:332 >>>> (gdb) quit >>>> >>>> The crash happens after selecting OK but not after selecting Cancel. The >>>> display is also odd before that (no line drawing, just odd text instead), >>>> but is sufficient to be usable at that stage. >>>> >>> >>> This is an indication that something is missing in dialog4ports which >>> is required by FBSD-14 but not FBSD-13. I had a similar problem with >>> dialog4ports under FBSD-14 some weeks ago, because i had a really old >>> version installed. After upgrading it using the pkg repositories for >>> FBSD-14 all problems, in particular garbled text, disappeared. >>> >>> IIRC there were updates to ncurses in FBSD-14 fairly recently which >>> would explain the problem with old versions of dialog4ports. >> >> I do (and did) my own port builds with poudriere-devel. See the >> version of ports below. In summary: my dialog4ports is >> based on 4116dc2f of ports (CommitDate: 2021-10-17 21:52:37 +0000). >> >> However it was deliberately built in/for a releng/13.0 based >> context then also used under main [so:14]. >> >> For ports not requiring kernel vintage matching, newer systems >> versions generally allow running software built for older FreeBSD >> systems (going back a fair distance, anyway). dialog4ports does >> not appear to require kernel vintage matching. I do not install >> any ports requiring kernel vintage matching. > > IIRC, dialog4ports case wouldn't be a kernel-related. > For ncurses libraries, main (aka 14-current) fully switched to *w ones > and deleted non-*w ones. And dialog4ports built with 13 and earlier > crashed on 14. So I did a chroot into a bectl mount of my stable/13 13S-amd64-nodbg and looked: # ldd `which dialog4ports` /usr/local/bin/dialog4ports: libncursesw.so.9 => /lib/libncursesw.so.9 (0x800248000) libm.so.5 => /lib/libm.so.5 (0x8002bc000) libdialog.so.9 => /usr/lib/libdialog.so.9 (0x8002f3000) libc.so.7 => /lib/libc.so.7 (0x80032d000) # ldd /usr/lib/libdialog.so.9 /usr/lib/libdialog.so.9: libncursesw.so.9 => /lib/libncursesw.so.9 (0x8006a7000) libm.so.5 => /lib/libm.so.5 (0x80071b000) libc.so.7 => /lib/libc.so.7 (0x800261000) This context worked fine for OK selection but note that there is libncursesw.so.9 use (so: *w in use). The problem is not libncursesw.so vs. libncurses.so use. Instead it seems to be the split between: libncursesw.so.9 and: libtinfow.so.9 in main [so: 14] that looks to be the difference that matters. Somehow the binding to libtinfow.so.9 in main is insufficient to allow full use of the releng/13.0 based dialog4ports build. (For all I know, this might be expected.) For reference for the stable/13 test: # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400036 1300516 # ~/fbsd-based-on-what-commit.sh branch: stable/13 merge-base: 0e5787b1d089310448fdc7b9855f1f0701965d8d merge-base: CommitDate: 2021-10-09 03:01:17 +0000 0e5787b1d089 (HEAD -> stable/13, freebsd/stable/13) ti(4): Fix a typo in an error message n247583 (--first-parent --count for merge-base) The chroot had a mount_null of the same /usr/local/ as was used for the main [14] activity. (And a mount_null of the same /usr/ports/ that was in use for the main activity.) >> >>>> I've not had any other of the ports that I built in/for releng/13.0 >>>> (and have used) fail to operate under main [so: under 14]. (But the >>>> variety used is not wide.) >>>> >>>> For reference . . . >>>> >>>> # uname -apKU >>>> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400036 1400036 >>>> >>>> (Not a debug build but has debug symbols enabled.) >>>> >>>> # pwd >>>> /usr/ports >>>> # ~/fbsd-based-on-what-commit.sh >>>> branch: main >>>> merge-base: 4116dc2f1f6385b42fb668badb6b4c1cbb195f9d >>>> merge-base: CommitDate: 2021-10-17 21:52:37 +0000 >>>> 4116dc2f1f63 (HEAD -> main, freebsd/main, freebsd/HEAD) ports-mgmt/poudriere-devel: Update to 3.3.0-1022-g964cf327f >>>> n562472 (--first-parent --count for merge-base) >> >> The above indicates the vintage of ports that my dialog4ports >> build is based on (in detail): Not all that old at this point. >> >>>> # file `which dialog4ports` >>>> /usr/local/bin/dialog4ports: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300139), FreeBSD-style, with debug_info, not stripped >>>> >>>> # ldd `which dialog4ports` >>>> /usr/local/bin/dialog4ports: >>>> libncursesw.so.9 => /lib/libncursesw.so.9 (0x800248000) >>>> libm.so.5 => /lib/libm.so.5 (0x800281000) >>>> libdialog.so.9 => /usr/lib/libdialog.so.9 (0x8002b8000) >>>> libc.so.7 => /lib/libc.so.7 (0x8002f6000) >>>> libtinfow.so.9 => /lib/libtinfow.so.9 (0x800703000) >>>> >>>> Note: The dialog4ports is a non-debug build but with debug symbols, >>>> as is normal for my port builds via poudriere-devel . >>>> >>>> As for the poudriere-devel build context for the ports: >>>> >>>> # chroot /usr/obj/DESTDIRs/13_0R-amd64-poud/ >>>> # uname -apKU >>>> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400036 1300139 >>>> >>>> # cd /usr/13_0R-src/ >>>> # ~/fbsd-based-on-what-commit.sh >>>> branch: releng/13.0 >>>> merge-base: 940681634ee17d12225ecd722c07fef1a0bde813 >>>> merge-base: CommitDate: 2021-08-24 18:23:29 +0000 >>>> 940681634ee1 (HEAD -> releng/13.0, freebsd/releng/13.0) Add UPDATING entries and bump version. >>>> n244760 (--first-parent --count for merge-base) >> >> >> === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)