Re: stable/12 broken?
On Fri, Feb 22, 2019 at 7:39 AM Antoine Brodin wrote: > Hi, > > For your information, the stable/12 branch seems broken, at least on > i386, there is a segmentation fault when trying to run binaries and 0 > package can be produced. > The regression happened between > SVN Revision: Jail stable/12 -> 344262 > and > SVN Revision: Jail stable/12 -> 344454 The onlly relevant commit seems to be: Author: kib Date: Thu Feb 21 12:13:27 2019 New Revision: 344436 URL: https://svnweb.freebsd.org/changeset/base/344436 Log: MFC r344120: Unify i386 and amd64 getcontextx.c, and use ifuncs while there. Antoine ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
stable/12 broken?
Hi, For your information, the stable/12 branch seems broken, at least on i386, there is a segmentation fault when trying to run binaries and 0 package can be produced. The regression happened between SVN Revision: Jail stable/12 -> 344262 and SVN Revision: Jail stable/12 -> 344454 Antoine ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Java support
On 21/02/2019 18:00, Aristedes Maniatis wrote: > On 21/2/19 9:18pm, Kurt Jaeger wrote: >> Are there plans for the Foundation to sponsor some work in this area? >> Your point is, that the FreeBSD community should do regular testbuilds >> for >> >> https://github.com/AdoptOpenJDK/openjdk-jdk9u/ >> https://github.com/AdoptOpenJDK/openjdk-jdk10u/ >> https://github.com/AdoptOpenJDK/openjdk-jdk11u/ >> >> and provide patches if something does not build or work, right ? >> >> And, if necessary, fund someone to do that work ? > > > Yes. Although I don't think there is a need to worry about the short > term releases 9 and 10. Only the LTS branches like JDK11 are being > supported by many OS vendors. > > https://access.redhat.com/articles/1299013 > > > My concern is that it might be beyond the capability of the open source > community to do the amount of work required here in a timely manner, and > so this might be an opportunity for the Foundation to step in and and > ensure this vital work is done. Perhaps ongoing maintenance is easier > once AdoptOpenJDK is brought up to speed on the BSD bits required. > I don't think this is beyond the open source community's capabilities at all; quite the opposite. The real crux is individual priorities. Please refer to the following PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222568 The last comment there is exactly the point of what I had typed in an earlier incarnation of this email message before I had some second thoughts on just how rude it could come off. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use; replace local-part with vishwin for off-list communication if possible) signature.asc Description: OpenPGP digital signature
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
21.02.2019 22:27, Harry Schmalzbauer wrote: >> The object is clearly corrupted. > > Thanks to your hint to readelf, I found out that it gets corrupted during > dump(8) (or resotore, not yet analyzed). > The obj tree contains the good version, the dump archive not. > The dump archive is used as source for the ISO, hence the described errors. > Now I have to dig in 10 years old deployment scripts to track down and > reproduce the corruption. No explanation so far, but for sure no rtld-elf > problem :-) > And also not a problem in the FreeBSD make chain, building stable/12 on > stable/11 works as intended and doesn't produce the mutilated > libcrypto.so.111! You may find useful reading trail of this PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228174 Long story short: dump(8) will read inconsistent data (or even garbage) from mounted file system unless used with -L to make and dump a snapshot. And UFS snapshots are not compatible with SU+J UFS created with installer by default in some versions of FreeBSD. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Java support
On 21/2/19 9:18pm, Kurt Jaeger wrote: Are there plans for the Foundation to sponsor some work in this area? Your point is, that the FreeBSD community should do regular testbuilds for https://github.com/AdoptOpenJDK/openjdk-jdk9u/ https://github.com/AdoptOpenJDK/openjdk-jdk10u/ https://github.com/AdoptOpenJDK/openjdk-jdk11u/ and provide patches if something does not build or work, right ? And, if necessary, fund someone to do that work ? Yes. Although I don't think there is a need to worry about the short term releases 9 and 10. Only the LTS branches like JDK11 are being supported by many OS vendors. https://access.redhat.com/articles/1299013 My concern is that it might be beyond the capability of the open source community to do the amount of work required here in a timely manner, and so this might be an opportunity for the Foundation to step in and and ensure this vital work is done. Perhaps ongoing maintenance is easier once AdoptOpenJDK is brought up to speed on the BSD bits required. Functioning Java is (IMO) a critical part of a modern server operating system. Cheers Ari ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2019-02-17
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-02-17 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-02-11 to 2019-02-17. During this period, we have: * 2348 builds (93.4% passed, 6.6% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 553 test runs (23.7% passed, 73.6% unstable, 2.7% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 12 doc buils (100% passed) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. Web version of this report is available at https://hackmd.io/s/By8HaYcSV and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big These two began failing since r343964 and do not show up after r344128. ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 See https://bugs.freebsd.org/235200 and https://bugs.freebsd.org/234809 for deails. WIP: https://bugs.freebsd.org/234809 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 see https://bugs.freebsd.org/235200 and https://bugs.freebsd.org/234809 for deails. WIP: https://bugs.freebsd.org/234809 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sbin.bectl.bectl_test.bectl_mount * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues ### Cause build fails * [29: genassym.o build race](https://bugs.freebsd.org/29) * Patch available: https://people.freebsd.org/~bdrewery/patches/PR29.diff * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ## Other News * QEMU has onboarded FreeBSD CI: https://cirrus-ci.com/github/qemu/qemu * New clang800-import project jobs added: * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-aarch64-build/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-amd64-build/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-amd64-test/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-i386-build/ * The artifacts are available at https://artifact.ci.freebsd.org/snapshot/clang800-import/ for further testing needs. * Jobs for testing if drm pkgs (graphics/drm-*) can be built fine on latest -current and -stable, are being tested in staging env. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Java support
On Thu, 21 Feb 2019 at 04:19, Kurt Jaeger wrote: > Hi! > > > With the Java FreeBSD mailing list pretty quiet, I thought I might ask > > here whether anyone was working on porting the latest Java versions over > > to FreeBSD. > > There's the openjdk port, java/openjdk8. > > You are asking about input from the FreeBSD community to openjdk9, 10 and > 11 ? > > > While Java 8 will be quite satisfactory for a while, the longer Java > > advances without BSD patches the harder it will be to bring across all > > the good work done for Java 8 on FreeBSD. > > This is correct. > > > Are there plans for the Foundation to sponsor some work in this area? > > Your point is, that the FreeBSD community should do regular testbuilds for > > https://github.com/AdoptOpenJDK/openjdk-jdk9u/ > https://github.com/AdoptOpenJDK/openjdk-jdk10u/ > https://github.com/AdoptOpenJDK/openjdk-jdk11u/ > > and provide patches if something does not build or work, right ? > > And, if necessary, fund someone to do that work ? Just looking at https://en.wikipedia.org/wiki/Java_version_history, it would appear that Java 9 and Java 10 are no longer supported, and, FWIIW, Java 8 is actually planned to be supported longer than Java 11, at least in the context of AdoptOpenJDK, so, there's that. C. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
Am 21.02.2019 um 10:36 schrieb Konstantin Belousov: … ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:FreeBSD ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices x86-64 Version: 0x1 Entry point address: 0x116000 Start of program headers: 64 (bytes into file) Start of section headers: 3090864 (bytes into file) Flags: 0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 29 Section header string table index: 28 Elf file type is DYN (Shared object file) Entry point 0x116000 There are 8 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz FlgAlign PHDR 0x0040 0x0040 0x0040 0x01c0 0x01c0 R 0x8 LOAD 0x 0x 0x 0x00115a7c 0x00115a7c R 0x1000 LOAD 0x00116000 0x00116000 0x00116000 0x001acb20 0x001acb20 R E0x1000 LOAD 0x002c3000 0x002c3000 0x002c3000 0x0002f790 0x000325e0 RW 0x1000 DYNAMIC0x002f1a80 0x002f1a80 0x002f1a80 0x0190 0x0190 RW 0x8 GNU_RELRO 0x002c9000 0x002c9000 0x002c9000 0x00029790 0x00029790 R 0x1 GNU_EH_FRAME 0x000d0050 0x000d0050 0x000d0050 0xbc74 0xbc74 R 0x4 GNU_STACK 0x 0x 0x 0x 0x RW 0 Section to Segment mapping: Segment Sections... 00 01 (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) 02 03 04 05 06 07 (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) There are 29 section headers, starting at offset 0x2f29b0: … The object is clearly corrupted. Thanks to your hint to readelf, I found out that it gets corrupted during dump(8) (or resotore, not yet analyzed). The obj tree contains the good version, the dump archive not. The dump archive is used as source for the ISO, hence the described errors. Now I have to dig in 10 years old deployment scripts to track down and reproduce the corruption. No explanation so far, but for sure no rtld-elf problem :-) And also not a problem in the FreeBSD make chain, building stable/12 on stable/11 works as intended and doesn't produce the mutilated libcrypto.so.111! Thanks, -harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Java support
Hi! > With the Java FreeBSD mailing list pretty quiet, I thought I might ask > here whether anyone was working on porting the latest Java versions over > to FreeBSD. There's the openjdk port, java/openjdk8. You are asking about input from the FreeBSD community to openjdk9, 10 and 11 ? > While Java 8 will be quite satisfactory for a while, the longer Java > advances without BSD patches the harder it will be to bring across all > the good work done for Java 8 on FreeBSD. This is correct. > Are there plans for the Foundation to sponsor some work in this area? Your point is, that the FreeBSD community should do regular testbuilds for https://github.com/AdoptOpenJDK/openjdk-jdk9u/ https://github.com/AdoptOpenJDK/openjdk-jdk10u/ https://github.com/AdoptOpenJDK/openjdk-jdk11u/ and provide patches if something does not build or work, right ? And, if necessary, fund someone to do that work ? -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
Hello, I don’t know if this is related or not, but when I compile the Nextcloud client port https://svnweb.freebsd.org/ports/head/deskutils/nextcloudclient/ on 11.2 by setting DEFAULT_VERSIONS+=ssl=openssl111 it dumps core, too. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
On Thu, Feb 21, 2019 at 10:03:29AM +0100, Harry Schmalzbauer wrote: > Am 21.02.2019 um 09:54 schrieb Konstantin Belousov: > > On Thu, Feb 21, 2019 at 09:24:43AM +0100, Harry Schmalzbauer wrote: > >> Am 20.02.2019 um 17:51 schrieb Harry Schmalzbauer: > >>> Hello, > >>> > >> … > >>> gdb shows: > >>> Core was generated by `/usr/sbin/auditdistd'. > >>> Program terminated with signal 11, Segmentation fault. > >>> Reading symbols from /lib/libutil.so.9...Reading symbols from > >>> /usr/lib/debug//lib/libutil.so.9.debug...done. > >>> done. > >>> Loaded symbols for /lib/libutil.so.9 > >>> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from > >>> /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > >>> done. > >>> Loaded symbols for /libexec/ld-elf.so.1 > >>> #0 memset (dest=0x80056f790, c=0, len=) > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > >>> 5624 ((char *)dest)[i] = c; > >>> (gdb) bt > >>> #0 memset (dest=0x80056f790, c=0, len=) > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > >>> #1 0x000800235b07 in map_object (fd=3, path=0x800246140 > >>> "/lib/libcrypto.so.111", > >>> sb=0x7fffd4a8) > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 > >>> #2 0x000800230806 in load_object (name=0x201dba > >>> "libcrypto.so.111", fd_u=-1, > >>> refobj=0x800248000, flags=) > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 > >>> #3 0x000800229972 in _rtld (sp=, > >>> exit_proc=0x7fffea30, > >>> objp=0x7fffea38) > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 > >>> #4 0x000800228019 in .rtld_start () > >>> at > >>> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 > >>> #5 0x in ?? () > >>> Current language: auto; currently minimal > >>> > >>> Any help highly appreciated. > >>> > >>> This is with a live CD (amd64), compiled with stable/12 from today (so > >>> clang 7.01). > >>> The bhyve guest has 2GB hardwired and ran stable/11 beforehand, which > >>> compiled the live CD. > >>> bhyve host is 11.2. But that shouldn't play a role, does it? > >> > >> I'm really interested what happens here. > >> I built stable/11 in that bhyve guest and updated that guest to > >> stable/11 from yesterday. > >> To my surpise llvm 7.01 was also merged to stable/11. Thank you for > >> that great supprt! > >> No problems with any binary in the stable/11 bhyve guest. > >> > >> Then I built stable/12 in that re-built stable/11 guest. > >> As result, again all binaries linked to /lib/libcrypto.so.111 crash > >> (signal 11) with the stable/12 iso in the same bhyve guest. > >> > >> Here the example from ntpq: > >> Program terminated with signal 11, Segmentation fault. > >> Reading symbols from /lib/libedit.so.7...Reading symbols from > >> /usr/lib/debug//lib/libedit.so.7.debug...done. > >> done. > >> Loaded symbols for /lib/libedit.so.7 > >> Reading symbols from /lib/libm.so.5...Reading symbols from > >> /usr/lib/debug//lib/libm.so.5.debug...done. > >> done. > >> Loaded symbols for /lib/libm.so.5 > >> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from > >> /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > >> done. > >> #0 memset (dest=0x8005ef790, c=0, len=) at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > >> 5624 ((char *)dest)[i] = c; > >> (gdb) bt > >> #0 memset (dest=0x8005ef790, c=0, len=) at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > >> #1 0x00080025db07 in map_object (fd=3, path=0x80026e1a0 > >> "/lib/libcrypto.so.111", sb=0x7fffd4c8) at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 > >> #2 0x000800258806 in load_object (name=0x201b40 "libcrypto.so.111", > >> fd_u=-1, refobj=0x80027, flags=) at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 > >> #3 0x000800251972 in _rtld (sp=, > >> exit_proc=0x7fffea50, objp=0x7fffea58) at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 > >> #4 0x000800250019 in .rtld_start () at > >> /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 > >> #5 0x in ?? () > >> > >> So please correct me if I'm comletely wrong, but the problem here seems > >> to be reproducably rtld-elf related. > >> Unfortunately I don't know anything about object files and linkers and > >> the related fundamental stuff. > > If you do not know about linkers, why do you claim that the problem > > is related to rtld ? > > > >> But maybe someone else has an idea what's going wrong here? > > > > The fault happens during zeroing of bss. Most likely it is due to some > > strangeness of the object being l
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
Am 21.02.2019 um 09:54 schrieb Konstantin Belousov: On Thu, Feb 21, 2019 at 09:24:43AM +0100, Harry Schmalzbauer wrote: Am 20.02.2019 um 17:51 schrieb Harry Schmalzbauer: Hello, … gdb shows: Core was generated by `/usr/sbin/auditdistd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libutil.so.9...Reading symbols from /usr/lib/debug//lib/libutil.so.9.debug...done. done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 memset (dest=0x80056f790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 5624 ((char *)dest)[i] = c; (gdb) bt #0 memset (dest=0x80056f790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 #1 0x000800235b07 in map_object (fd=3, path=0x800246140 "/lib/libcrypto.so.111", sb=0x7fffd4a8) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 #2 0x000800230806 in load_object (name=0x201dba "libcrypto.so.111", fd_u=-1, refobj=0x800248000, flags=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 #3 0x000800229972 in _rtld (sp=, exit_proc=0x7fffea30, objp=0x7fffea38) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 #4 0x000800228019 in .rtld_start () at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 #5 0x in ?? () Current language: auto; currently minimal Any help highly appreciated. This is with a live CD (amd64), compiled with stable/12 from today (so clang 7.01). The bhyve guest has 2GB hardwired and ran stable/11 beforehand, which compiled the live CD. bhyve host is 11.2. But that shouldn't play a role, does it? I'm really interested what happens here. I built stable/11 in that bhyve guest and updated that guest to stable/11 from yesterday. To my surpise llvm 7.01 was also merged to stable/11. Thank you for that great supprt! No problems with any binary in the stable/11 bhyve guest. Then I built stable/12 in that re-built stable/11 guest. As result, again all binaries linked to /lib/libcrypto.so.111 crash (signal 11) with the stable/12 iso in the same bhyve guest. Here the example from ntpq: Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libedit.so.7...Reading symbols from /usr/lib/debug//lib/libedit.so.7.debug...done. done. Loaded symbols for /lib/libedit.so.7 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. #0 memset (dest=0x8005ef790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 5624 ((char *)dest)[i] = c; (gdb) bt #0 memset (dest=0x8005ef790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 #1 0x00080025db07 in map_object (fd=3, path=0x80026e1a0 "/lib/libcrypto.so.111", sb=0x7fffd4c8) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 #2 0x000800258806 in load_object (name=0x201b40 "libcrypto.so.111", fd_u=-1, refobj=0x80027, flags=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 #3 0x000800251972 in _rtld (sp=, exit_proc=0x7fffea50, objp=0x7fffea58) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 #4 0x000800250019 in .rtld_start () at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 #5 0x in ?? () So please correct me if I'm comletely wrong, but the problem here seems to be reproducably rtld-elf related. Unfortunately I don't know anything about object files and linkers and the related fundamental stuff. If you do not know about linkers, why do you claim that the problem is related to rtld ? But maybe someone else has an idea what's going wrong here? The fault happens during zeroing of bss. Most likely it is due to some strangeness of the object being loaded. For diagnostic, show the output of "readelf -a libcrypto.so.111". Thanks for your help! I just guess it's rtld related, since I obviously misinterpreted the backtrace. Reverting topic change… ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:FreeBSD ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Mi
Re: Strange rtld-elf failure on stable/12 [Was: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)]
On Thu, Feb 21, 2019 at 09:24:43AM +0100, Harry Schmalzbauer wrote: > Am 20.02.2019 um 17:51 schrieb Harry Schmalzbauer: > > Hello, > > > … > > gdb shows: > > Core was generated by `/usr/sbin/auditdistd'. > > Program terminated with signal 11, Segmentation fault. > > Reading symbols from /lib/libutil.so.9...Reading symbols from > > /usr/lib/debug//lib/libutil.so.9.debug...done. > > done. > > Loaded symbols for /lib/libutil.so.9 > > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from > > /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > > done. > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 memset (dest=0x80056f790, c=0, len=) > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > > 5624 ((char *)dest)[i] = c; > > (gdb) bt > > #0 memset (dest=0x80056f790, c=0, len=) > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > > #1 0x000800235b07 in map_object (fd=3, path=0x800246140 > > "/lib/libcrypto.so.111", > > sb=0x7fffd4a8) > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 > > #2 0x000800230806 in load_object (name=0x201dba > > "libcrypto.so.111", fd_u=-1, > > refobj=0x800248000, flags=) > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 > > #3 0x000800229972 in _rtld (sp=, > > exit_proc=0x7fffea30, > > objp=0x7fffea38) > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 > > #4 0x000800228019 in .rtld_start () > > at > > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 > > #5 0x in ?? () > > Current language: auto; currently minimal > > > > Any help highly appreciated. > > > > This is with a live CD (amd64), compiled with stable/12 from today (so > > clang 7.01). > > The bhyve guest has 2GB hardwired and ran stable/11 beforehand, which > > compiled the live CD. > > bhyve host is 11.2. But that shouldn't play a role, does it? > > I'm really interested what happens here. > I built stable/11 in that bhyve guest and updated that guest to > stable/11 from yesterday. > To my surpise llvm 7.01 was also merged to stable/11. Thank you for > that great supprt! > No problems with any binary in the stable/11 bhyve guest. > > Then I built stable/12 in that re-built stable/11 guest. > As result, again all binaries linked to /lib/libcrypto.so.111 crash > (signal 11) with the stable/12 iso in the same bhyve guest. > > Here the example from ntpq: > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libedit.so.7...Reading symbols from > /usr/lib/debug//lib/libedit.so.7.debug...done. > done. > Loaded symbols for /lib/libedit.so.7 > Reading symbols from /lib/libm.so.5...Reading symbols from > /usr/lib/debug//lib/libm.so.5.debug...done. > done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from > /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > done. > #0 memset (dest=0x8005ef790, c=0, len=) at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > 5624 ((char *)dest)[i] = c; > (gdb) bt > #0 memset (dest=0x8005ef790, c=0, len=) at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 > #1 0x00080025db07 in map_object (fd=3, path=0x80026e1a0 > "/lib/libcrypto.so.111", sb=0x7fffd4c8) at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 > #2 0x000800258806 in load_object (name=0x201b40 "libcrypto.so.111", > fd_u=-1, refobj=0x80027, flags=) at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 > #3 0x000800251972 in _rtld (sp=, > exit_proc=0x7fffea50, objp=0x7fffea58) at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 > #4 0x000800250019 in .rtld_start () at > /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 > #5 0x in ?? () > > So please correct me if I'm comletely wrong, but the problem here seems > to be reproducably rtld-elf related. > Unfortunately I don't know anything about object files and linkers and > the related fundamental stuff. If you do not know about linkers, why do you claim that the problem is related to rtld ? > But maybe someone else has an idea what's going wrong here? The fault happens during zeroing of bss. Most likely it is due to some strangeness of the object being loaded. For diagnostic, show the output of "readelf -a libcrypto.so.111". ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Strange rtld-elf failure on stable/12 [Was: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)]
Am 20.02.2019 um 17:51 schrieb Harry Schmalzbauer: Hello, … gdb shows: Core was generated by `/usr/sbin/auditdistd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libutil.so.9...Reading symbols from /usr/lib/debug//lib/libutil.so.9.debug...done. done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 memset (dest=0x80056f790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 5624 ((char *)dest)[i] = c; (gdb) bt #0 memset (dest=0x80056f790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 #1 0x000800235b07 in map_object (fd=3, path=0x800246140 "/lib/libcrypto.so.111", sb=0x7fffd4a8) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 #2 0x000800230806 in load_object (name=0x201dba "libcrypto.so.111", fd_u=-1, refobj=0x800248000, flags=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 #3 0x000800229972 in _rtld (sp=, exit_proc=0x7fffea30, objp=0x7fffea38) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 #4 0x000800228019 in .rtld_start () at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 #5 0x in ?? () Current language: auto; currently minimal Any help highly appreciated. This is with a live CD (amd64), compiled with stable/12 from today (so clang 7.01). The bhyve guest has 2GB hardwired and ran stable/11 beforehand, which compiled the live CD. bhyve host is 11.2. But that shouldn't play a role, does it? I'm really interested what happens here. I built stable/11 in that bhyve guest and updated that guest to stable/11 from yesterday. To my surpise llvm 7.01 was also merged to stable/11. Thank you for that great supprt! No problems with any binary in the stable/11 bhyve guest. Then I built stable/12 in that re-built stable/11 guest. As result, again all binaries linked to /lib/libcrypto.so.111 crash (signal 11) with the stable/12 iso in the same bhyve guest. Here the example from ntpq: Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libedit.so.7...Reading symbols from /usr/lib/debug//lib/libedit.so.7.debug...done. done. Loaded symbols for /lib/libedit.so.7 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. #0 memset (dest=0x8005ef790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 5624 ((char *)dest)[i] = c; (gdb) bt #0 memset (dest=0x8005ef790, c=0, len=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:5624 #1 0x00080025db07 in map_object (fd=3, path=0x80026e1a0 "/lib/libcrypto.so.111", sb=0x7fffd4c8) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/map_object.c:249 #2 0x000800258806 in load_object (name=0x201b40 "libcrypto.so.111", fd_u=-1, refobj=0x80027, flags=) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2493 #3 0x000800251972 in _rtld (sp=, exit_proc=0x7fffea50, objp=0x7fffea58) at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/rtld.c:2315 #4 0x000800250019 in .rtld_start () at /usr/local/share/deploy-tools/RELENG_12/src/libexec/rtld-elf/amd64/rtld_start.S:39 #5 0x in ?? () So please correct me if I'm comletely wrong, but the problem here seems to be reproducably rtld-elf related. Unfortunately I don't know anything about object files and linkers and the related fundamental stuff. But maybe someone else has an idea what's going wrong here? Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
