Re: Segmentation fault running ntpd
David Wolfskill writes: > ... > bound to 172.17.1.245 -- renewal in 43200 seconds. > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > Starting Network: lo0 em0 iwn0 lagg0. > ... Did you find a solution? I'm wondering if the ntpd problems people are reporting on freebsd-security@ are related. I vaguely recall hearing that this had been traced to a pthread bug, but can't find anything about it in commit logs or mailing list archives. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
> On Oct 30, 2015, at 01:42, Dag-Erling Smørgrav wrote: > > David Wolfskill writes: >> ... >> bound to 172.17.1.245 -- renewal in 43200 seconds. >> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >> Starting Network: lo0 em0 iwn0 lagg0. >> ... > > Did you find a solution? I'm wondering if the ntpd problems people are > reporting on freebsd-security@ are related. I vaguely recall hearing > that this had been traced to a pthread bug, but can't find anything > about it in commit logs or mailing list archives. https://svnweb.freebsd.org/changeset/base/287591 ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
NGie Cooper writes: > Dag-Erling Smørgrav writes: > > David Wolfskill writes: > > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > > Did you find a solution? [...] > https://svnweb.freebsd.org/changeset/base/287591 ? Are you certain? The commit message does not mention David or ntpd. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
> On Oct 30, 2015, at 02:05, Dag-Erling Smørgrav wrote: > > NGie Cooper writes: >> Dag-Erling Smørgrav writes: >>> David Wolfskill writes: pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >>> Did you find a solution? [...] >> https://svnweb.freebsd.org/changeset/base/287591 ? > > Are you certain? The commit message does not mention David or ntpd. That commit was pretty involved. Peter documented the issue in the thread titled "ABORT! ABORT! Re: HEADS UP: this month's cluster refresh” that was sent to the internal list. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
> On Oct 30, 2015, at 02:18, Franco Fichtner wrote: > > Hi all, > > I did a quick test build and this seems to solve the ntpd crash issue > on top of releng/10.1. Makes sense … looking through my email r287591 was never MFCed back to stable/9 or stable/10 :/ . HTH, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
Hi all, I did a quick test build and this seems to solve the ntpd crash issue on top of releng/10.1. Cheers, Franco > On 30 Oct 2015, at 10:09 am, NGie Cooper wrote: > > >> On Oct 30, 2015, at 02:05, Dag-Erling Smørgrav wrote: >> >> NGie Cooper writes: >>> Dag-Erling Smørgrav writes: David Wolfskill writes: > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) Did you find a solution? [...] >>> https://svnweb.freebsd.org/changeset/base/287591 ? >> >> Are you certain? The commit message does not mention David or ntpd. > > That commit was pretty involved. Peter documented the issue in the thread > titled "ABORT! ABORT! Re: HEADS UP: this month's cluster refresh” that was > sent to the internal list. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
Well, it’s on stable/10 since September 16 and somebody reported that this particular branch would not trigger the crash along with HEAD, but any 10.x would. Can’t find the reference right now though. > On 30 Oct 2015, at 10:24 am, NGie Cooper wrote: > > >> On Oct 30, 2015, at 02:18, Franco Fichtner wrote: >> >> Hi all, >> >> I did a quick test build and this seems to solve the ntpd crash issue >> on top of releng/10.1. > > Makes sense … looking through my email r287591 was never MFCed back to > stable/9 or stable/10 :/ . > HTH, > -NGie > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
> On Oct 30, 2015, at 02:32, Franco Fichtner wrote: > > Well, it’s on stable/10 since September 16 and somebody reported that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can’t find the reference right now though. You’re right. My Mail.app search fu was failing me for a minute.. r287846 | kib | 2015-09-15 21:20:39 -0700 (Tue, 15 Sep 2015) | 4 lines MFC r287591: There is no reason in the current kernel to disallow write access to the COW wired entry if the entry permissions allow it. Remove the check. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
On 10/30/15 09:32, Franco Fichtner wrote: > Well, it’s on stable/10 since September 16 and somebody reported that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can’t find the reference right now though. That was me, amongst others. There are threads on security@ and questions@. >> On 30 Oct 2015, at 10:24 am, NGie Cooper wrote: >> >> >>> On Oct 30, 2015, at 02:18, Franco Fichtner wrote: >>> >>> Hi all, >>> >>> I did a quick test build and this seems to solve the ntpd crash issue >>> on top of releng/10.1. >> >> Makes sense … looking through my email r287591 was never MFCed back to >> stable/9 or stable/10 :/ . >> HTH, >> -NGie There were two problems reported: 1) ntpdc and ntpq would crash -- this was reported for 9.3-STABLE -- I don't think it affected other releases, and was diagnosed as due to a pthreads linking issue. Solved for 9.x in r290044 and r290046 2) ntpd SEGV's on startup on 10.2-RELEASE-p6 (possibly others). Curiously, so does net/ntp from ports, but only on the second startup. Exactly the same ntp package seems to run and restart just fine on recent 10-STABLE though. As does the base system ntpd. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: Segmentation fault running ntpd
Franco Fichtner writes: > Well, it’s on stable/10 since September 16 and somebody reported that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can’t find the reference right now though. OK, we should do an EN with that patch then, but we may have to include some of the other recent commits to the vm_map.c, which seem (at a quick glance) to be related. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote: > David Wolfskill writes: > > ... > > bound to 172.17.1.245 -- renewal in 43200 seconds. > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > > Starting Network: lo0 em0 iwn0 lagg0. > > ... > > Did you find a solution? I'm wondering if the ntpd problems people are > reporting on freebsd-security@ are related. I vaguely recall hearing > that this had been traced to a pthread bug, but can't find anything > about it in commit logs or mailing list archives. > I don't recall finding "a solution" per se; that said, I also don't recall seeing an occurrence of the above for enough time that I'm not sure when I sent that message. :-} As a reality check: g1-252(11.0-C)[1] ls -lT /*.core -rw-r--r-- 1 root wheel 13783040 Aug 18 04:19:03 2015 /ntpd.core g1-252(11.0-C)[2] So -- among other points -- my last sighting of whatever was causing that was the day I built: FreeBSD 11.0-CURRENT #157 r286880M/286880:1100079: Tue Aug 18 04:45:25 PDT 2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Note that the machines where I run head get updated daily (unless there's enough of a problem with head that I can't build it or can't boot it (and I'm unable to circumvent the issue within a reasonable time)) -- and while I do attempt to run ntpd on the machines, the above failure is more "annoying" than "crippling" in my particular case. And I'm presently running: FreeBSD 11.0-CURRENT #227 r290138M/290138:1100084: Thu Oct 29 05:12:58 PDT 2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 and building head @r290190 as I type. And FWIW, I *suspect* that one of the issues involved (in my case) was a ... lack of determinism ... in events involving getting the (wireless) network connectivity into a usable state as part of the initial transition to multi-user mode. (I only have evidence at the moment of the issue on my laptop; my build machine, which only uses a wired NIC, has no /ntpd.core file. It and my laptop are updated pretty much in lock-step; it runs a completely GENERIC kernel, while the laptop runs a modestly customized one based on GENERIC.) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
unsubscribe me please
Unsubscribe me please -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of freebsd-current-requ...@freebsd.org Sent: 30 October 2015 12:00 To: freebsd-current@freebsd.org Subject: freebsd-current Digest, Vol 627, Issue 5 Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288951: ifconfig -alias, arp not removed
On 10/29/2015 16:56, Bryan Drewery wrote: > On 10/29/2015 9:46 AM, Bryan Drewery wrote: >> On 10/29/15 9:42 AM, Eric van Gyzen wrote: >>> On 10/29/2015 11:25, Bryan Drewery wrote: # ifconfig igb0: flags=8843 metric 0 mtu 1500 options=403bb ether c8:0a:a9:04:39:78 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active # ifconfig igb0 inet 10.10.0.9 -alias # arp -an|grep 10.10.0.9 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] # arp -d 10.10.0.9 arp: writing to routing socket: Operation not permitted I swear this is not normal. I'm on an older build as well, r288951. >>> >>> That definitely looks abnormal. See what "route get" says. I think >>> that's the error you get when there is a route for that address. >>> >> >> # netstat -rn|grep 10.10.0.9 >> # route get 10.10.0.9 >>route to: lapbox >> destination: 10.10.0.0 >>mask: 255.255.0.0 >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >>0 0 0 0 1500 1 0 >> # route get 5.5.5.5 >>route to: 5.5.5.5 >> destination: default >>mask: default >> gateway: router.asus.com >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >>0 0 0 0 1500 1 0 >> >> For more context, this current system had 10.10.0.9 added to it. I >> started up a VM which also started using 10.10.0.9 and managed to "win" >> on the local network for owning it. (I don't know arp and this stuff >> well). I then came to this system to remove the alias and the arp entry >> to allow me to connect from it and have gotten into this situation. >> > > Just saw this in dmesg, which is what I described: > > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 The kernel should have removed the arp entry when you removed the alias. I just played with this on r289837 (one week old), and I could not reproduce the failure. In particular, r289501 sounds interesting, even though your interface is up. Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288951: ifconfig -alias, arp not removed
30.10.2015, 00:57, "Bryan Drewery" : > On 10/29/2015 9:46 AM, Bryan Drewery wrote: >> On 10/29/15 9:42 AM, Eric van Gyzen wrote: >>> On 10/29/2015 11:25, Bryan Drewery wrote: # ifconfig igb0: flags=8843 metric 0 mtu 1500 options=403bb ether c8:0a:a9:04:39:78 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active # ifconfig igb0 inet 10.10.0.9 -alias # arp -an|grep 10.10.0.9 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] # arp -d 10.10.0.9 arp: writing to routing socket: Operation not permitted I swear this is not normal. I'm on an older build as well, r288951. Well, there were changes on arpscrub procedures in r287789. (There was one bug fixed in r289501, but I think it is not relevant). Could you consider trying more recent HEAD and check if this is still reproducible? I was not able to reproduce that behavior. >>> >>> That definitely looks abnormal. See what "route get" says. I think >>> that's the error you get when there is a route for that address. >> >> # netstat -rn|grep 10.10.0.9 >> # route get 10.10.0.9 >> route to: lapbox >> destination: 10.10.0.0 >> mask: 255.255.0.0 >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0 >> # route get 5.5.5.5 >> route to: 5.5.5.5 >> destination: default >> mask: default >> gateway: router.asus.com >> fib: 0 >> interface: igb0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0 >> >> For more context, this current system had 10.10.0.9 added to it. I >> started up a VM which also started using 10.10.0.9 and managed to "win" >> on the local network for owning it. (I don't know arp and this stuff >> well). I then came to this system to remove the alias and the arp entry >> to allow me to connect from it and have gotten into this situation. > > Just saw this in dmesg, which is what I described: > > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 > on igb0 > > -- > Regards, > Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/console Change summaries: 290193 by zbb: Use PCB/LR from PCB rather from stack on armv7-gdb The kernel dump does not store these values on the stack. Use PCB structure to resolve PC and LR properly. Submitted by: Wojciech Macek Reviewed by: jhb, kib Obtained from: Semihalf Sponsored by: Juniper Networks Inc. Differential Revision: https://reviews.freebsd.org/D4013 290192 by zbb: Workaround KGDB issues on ARM by ignoring ARM EABI version higher than 5 To make KGDB working, it needs to understand kernel ELF image. By default it is compiled using EABI_5, which is not supported on the gdb-6. As a workaround, treat these images as EABI_2 because they share a lot of things in common. This workaround does not guarantee ALL funtionalities to work. Submitted by: Wojciech Macek Reviewed by: jhb Obtained from: Semihalf Sponsored by: Juniper Networks Inc. Differential Revision: https://reviews.freebsd.org/D4012 290191 by avg: l2arc: do not call trim_map_free() for blocks with zero b_asize b_asize can be zero if the block is compressed into an empty block (ZIO_COMPRESS_EMPTY) and the trim code asserts that meaningless zero-sized trimming is not attempted. The logic for calling trim_map_free() is extracted into a new function l2arc_trim() to minimize code duplication. PR: 203473 Reported by:Willem Jan Withagen Tested by: Willem Jan Withagen MFC after: 11 days 290190 by ngie: Fix compiler warnings with open_to_operation.c Other sidenotes: - Remove unused variables with main(..) - Convert errx/exit with -1 to errx/exit with 1 - Fix a bogus test in try_directory_open (expected_errno == expected_errno -> errno == expected_errno) [*] - Fix some warnings related to discarded qualifiers - Remove a bogus else-statement at the end of check_mmap_exec(..) in the successful case. mmap(2), POSIX, Linux, etc all don't state what the behavior is when mixing O_WRONLY + PROT_EXEC, so assume success for now to get the test program to pass again. PR: 201286 [*] MFC after: 1 week Submitted by: David Binderman Sponsored by: EMC / Isilon Storage Division 290188 by kib: The prefix for CLFLUSHOPT is 0x66. It was right on amd64. Sponsored by: The FreeBSD Foundation 290186 by ed: Make truss work for CloudABI processes on aarch64. This change copies over amd64-cloudabi64.c to aarch64-cloudabi.c and adjusts it to fetch the proper registers on aarch64. To reduce the amount of shared code, the errno conversion function is moved into a separate source file. Reviewed by:jhb, andrew Differential Revision: https://reviews.freebsd.org/D4023 290185 by ngie: Disable h_raw/h_read with gcc I forgot that these testcases fail with gcc 4.2.1; add a note to that effect MFC after: never Sponsored by: EMC / Isilon Storage Division 290184 by ngie: Fix a set but not used variable warning flagged by gcc 4.9 with lib/libc/ssp/h_readlink MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 290183 by ngie: - Re-enable h_raw with clang 3.7.0+ - Fix the compiler check to allow the test to be compiled for gcc PR: 196430 MFC after: never Sponsored by: EMC / Isilon Storage Division 290182 by ngie: Fix rtsold's usage message - Remove -a from the usage message example dealing with specific interfaces. -a only makes sense when not specifying an interface, such that it's to be run on all interfaces - Fix the pidfile option (it's -p, not -P) - Change `interfaces` to `interface` to match the manpage MFC after: 3 days PR: 173744 Sponsored by: EMC / Isilon Storage Division 290181 by ngie: Unbreak bsd.progs.mk with PROGS (but not PROGS_CXX) and when invoking the "one of many" targets, e.g. `make hello_world`, where hello_world is a C program Tested with: PROGS and PROGS_CXX MFC after: 1 week X-MFC with: r289289 Sponsored by: EMC / Isilon Storage Division 290180 by ngie: Follow up to roundup feature addition in r289203 - Rename -r to -R to avoid the clash with makefs -r in NetBSD - Note that -R is an FFS-specific option because it's not implemented in cd9660 today - Rename the roundup variable to "roundup-size" in the manpage and help text for consistency with other variables. - Bump .Dd (missed in r289203) PR: 203707 MFC after: 1 week X-MFC with: r289203 Differential Revision: https://reviews.freebsd.org/D3959 Reviewed by: adrian (earlier patch), emaste Sponsored by: EMC / Isilon Storage Division 290179 by ngie: Remove a set but unused variable in __getgroupmembership to fix a gcc 4.9+ warning MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290178 by ngie: Fix GOST engine cipher linkage by adding e_gost_err.c to SRCS so it picks up undefined symbols, like "ERR_load_GOS
Re: Segmentation fault running ntpd
Not sure if it's the same issue, but it sure looks like it is. I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5 to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just replaced the /usr/sbin/ntpd with a new one; then I restarted the ntpd. On all host but one this was successful: the new ntpd starts fine and works normally. But on one of these machines the ntpd process immediately crashes with SIGSEGV. That machine has an Intel Xeon cpu. It is not apparent to me in what way this machine differs from others, Played with some variations of ntpd on that host, here are some findings: - the new ntpd (that came with 10.2-RELEASE-p6) runs fine if it does *not* daemonize, i.e. ntpd with an option -n or -d stays attached to a terminal and works fine; the same happens when run under ktrace -d -i ntpd ... it works fine, even when it daemonizes; - the ntpd built from fresh net/ntp-devel behaves exactly the same: crashes on that machine when it daemonizes - a previous ntpd (from 10.2-RELEASE-p5) works fine, so I ended up downgrading ntpd to that previous version on that machine. Also a ntpd from a recent 10-STABLE when copied to that host runs fine there! I haven't tried yet to build it with debugging, or capture a core dump. Puzzling... Mark 2015-10-30 12:34, je David Wolfskill napisal On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote: David Wolfskill writes: > ... > bound to 172.17.1.245 -- renewal in 43200 seconds. > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > Starting Network: lo0 em0 iwn0 lagg0. > ... Did you find a solution? I'm wondering if the ntpd problems people are reporting on freebsd-security@ are related. I vaguely recall hearing that this had been traced to a pthread bug, but can't find anything about it in commit logs or mailing list archives. I don't recall finding "a solution" per se; that said, I also don't recall seeing an occurrence of the above for enough time that I'm not sure when I sent that message. :-} As a reality check: g1-252(11.0-C)[1] ls -lT /*.core -rw-r--r-- 1 root wheel 13783040 Aug 18 04:19:03 2015 /ntpd.core g1-252(11.0-C)[2] So -- among other points -- my last sighting of whatever was causing that was the day I built: FreeBSD 11.0-CURRENT #157 r286880M/286880:1100079: Tue Aug 18 04:45:25 PDT 2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Note that the machines where I run head get updated daily (unless there's enough of a problem with head that I can't build it or can't boot it (and I'm unable to circumvent the issue within a reasonable time)) -- and while I do attempt to run ntpd on the machines, the above failure is more "annoying" than "crippling" in my particular case. And I'm presently running: FreeBSD 11.0-CURRENT #227 r290138M/290138:1100084: Thu Oct 29 05:12:58 PDT 2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 and building head @r290190 as I type. And FWIW, I *suspect* that one of the issues involved (in my case) was a ... lack of determinism ... in events involving getting the (wireless) network connectivity into a usable state as part of the initial transition to multi-user mode. (I only have evidence at the moment of the issue on my laptop; my build machine, which only uses a wired NIC, has no /ntpd.core file. It and my laptop are updated pretty much in lock-step; it runs a completely GENERIC kernel, while the laptop runs a modestly customized one based on GENERIC.) Peace, david ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
Hi Bryan/Simon! I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in obj.powerpc? I ran into the same issue on ref11-amd64.freebsd.org when I ran “make tinderbox". Thanks! -NGie % make buildworld TARGET=powerpc TARGET_ARCH=powerpc … ===> cddl/usr.sbin/dtrace/tests/common/json (all) (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe ) cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=gnu99 -fstack-protector-strong-c /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o *** Error code 1 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[HEADSUP] OpenSSL updated to 1.0.2d
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL on head has been updated to 1.0.2d. Please make sure to recompile all binaries depending on libcrypto.so.7 or libssl.so.7. Cheers! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ 0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2 wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk= =Wa/Z -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS > and I ran into this linker issue below. I have no idea (yet) why it’s trying > to compile an x64 object when I specify powerpc/powerpc — and more > importantly, why is the object not being put in obj.powerpc? > I ran into the same issue on ref11-amd64.freebsd.org when I ran “make > tinderbox". > Thanks! > -NGie > Have you modified any of your local toolchain handling, or skipped CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and there to be a lot more reports if there was a problem with buildworld cross compiling. > % make buildworld TARGET=powerpc TARGET_ARCH=powerpc > … > ===> cddl/usr.sbin/dtrace/tests/common/json (all) > (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe ) > cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g > -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json > -std=gnu99 -fstack-protector-strong-c > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c > -o tst.usdt.o > dtrace -C -x nolibs -G -o usdt.o -s > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d > tst.usdt.o > dtrace: failed to link script > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > *** Error code 1 > $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF > 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On 10/30/2015 1:57 PM, NGie Cooper wrote: >> Hi Bryan/Simon! >> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >> and I ran into this linker issue below. I have no idea (yet) why it’s trying >> to compile an x64 object when I specify powerpc/powerpc — and more >> importantly, why is the object not being put in obj.powerpc? >> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make >> tinderbox". >> Thanks! >> -NGie >> > > Have you modified any of your local toolchain handling, or skipped > CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > there to be a lot more reports if there was a problem with buildworld > cross compiling. > >> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc >> … >> ===> cddl/usr.sbin/dtrace/tests/common/json (all) >> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && >> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f >> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile >> _RECURSING_PROGS= PROG=tst.usdt.exe ) >> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g >> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json >> -std=gnu99 -fstack-protector-strong-c >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c >> -o tst.usdt.o >> dtrace -C -x nolibs -G -o usdt.o -s >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d >> tst.usdt.o >> dtrace: failed to link script >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >> incorrect ELF machine type for object file: tst.usdt.o >> *** Error code 1 >> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF >> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed to be fine with PROGS. Here's a test object built via PROGS: ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o ~/git/freebsd # file /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o I see nothing special with the DTRACE_TESTS to change any of this. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > On 10/30/2015 2:21 PM, Bryan Drewery wrote: >> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>> Hi Bryan/Simon! >>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >>> and I ran into this linker issue below. I have no idea (yet) why it’s >>> trying to compile an x64 object when I specify powerpc/powerpc — and more >>> importantly, why is the object not being put in obj.powerpc? >>> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make >>> tinderbox". >>> Thanks! >>> -NGie >>> >> >> Have you modified any of your local toolchain handling, or skipped >> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and >> there to be a lot more reports if there was a problem with buildworld >> cross compiling. >> >>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc >>> … >>> ===> cddl/usr.sbin/dtrace/tests/common/json (all) >>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && >>> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f >>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile >>> _RECURSING_PROGS= PROG=tst.usdt.exe ) >>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g >>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json >>> -std=gnu99 -fstack-protector-strong-c >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c >>> -o tst.usdt.o >>> dtrace -C -x nolibs -G -o usdt.o -s >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d >>> tst.usdt.o >>> dtrace: failed to link script >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >>> incorrect ELF machine type for object file: tst.usdt.o >>> *** Error code 1 >>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> $ file >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF >>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >>> > > I ran a buildworld with TARGET=powerpc just a few days ago and it seemed > to be fine with PROGS. Here's a test object built via PROGS: > > ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > ~/git/freebsd # file > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: > ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > not stripped > -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > > I see nothing special with the DTRACE_TESTS to change any of this. I could see there being a possible issue with my host VM, but I haven't modified my environment in ref11-amd64.freebsd.org at all. Could you please try reproing it there with your user? Thanks, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On 10/30/2015 3:03 PM, NGie Cooper wrote: > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: Hi Bryan/Simon! I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in obj.powerpc? I ran into the same issue on ref11-amd64.freebsd.org when I ran “make tinderbox". Thanks! -NGie >>> >>> Have you modified any of your local toolchain handling, or skipped >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and >>> there to be a lot more reports if there was a problem with buildworld >>> cross compiling. >>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc … ===> cddl/usr.sbin/dtrace/tests/common/json (all) (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe ) cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=gnu99 -fstack-protector-strong-c /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o *** Error code 1 The problem looks specific to compiling of .d files using dtrace(1). It must not have cross-compile support. The manpage does say: "The D compiler produces programs using the native data model of the operating system kernel.". So these will need to be disabled for non-native builds. I don't know if it would be possible to build a cross-compile version of dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. $ find /usr/obj/usr/src/svn/ -name tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >> >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed >> to be fine with PROGS. Here's a test object built via PROGS: >> >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> ~/git/freebsd # file >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), >> not stripped >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> >> I see nothing special with the DTRACE_TESTS to change any of this. > > I could see there being a possible issue with my host VM, but I > haven't modified my environment in ref11-amd64.freebsd.org at all. > > Could you please try reproing it there with your user? > > Thanks, > -NGie > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: > On 10/30/2015 3:03 PM, NGie Cooper wrote: > > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: > >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > I tried doing buildworld on powerpc/powerpc with > -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no > idea (yet) why it’s trying to compile an x64 object when I specify > powerpc/powerpc — and more importantly, why is the object not being put > in obj.powerpc? > I ran into the same issue on ref11-amd64.freebsd.org when I ran > “make tinderbox". > Thanks! > -NGie > > >>> > >>> Have you modified any of your local toolchain handling, or skipped > >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > >>> there to be a lot more reports if there was a problem with buildworld > >>> cross compiling. > >>> > % make buildworld TARGET=powerpc TARGET_ARCH=powerpc > … > ===> cddl/usr.sbin/dtrace/tests/common/json (all) > (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe ) > cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g > -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json > -std=gnu99 -fstack-protector-strong-c > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c > -o tst.usdt.o > dtrace -C -x nolibs -G -o usdt.o -s > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d > tst.usdt.o > dtrace: failed to link script > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > *** Error code 1 > > The problem looks specific to compiling of .d files using dtrace(1). It > must not have cross-compile support. > > The manpage does say: "The D compiler produces programs using the native > data model of the operating system kernel.". > > So these will need to be disabled for non-native builds. > > I don't know if it would be possible to build a cross-compile version of > dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. In the snippet above, tst.usdt.o is generated by cc, not dtrace(1). dtrace is complaining that the input file doesn't have the expected machine type, which seems valid given the file(1) output below. > > $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > $ file > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > > >> > >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed > >> to be fine with PROGS. Here's a test object built via PROGS: > >> > >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> ~/git/freebsd # file > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: > >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > >> not stripped > >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> > >> I see nothing special with the DTRACE_TESTS to change any of this. > > > > I could see there being a possible issue with my host VM, but I > > haven't modified my environment in ref11-amd64.freebsd.org at all. > > > > Could you please try reproing it there with your user? > > > > Thanks, > > -NGie > > > > > -- > Regards, > Bryan Drewery > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On 10/30/2015 4:08 PM, Mark Johnston wrote: > On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: >> On 10/30/2015 3:03 PM, NGie Cooper wrote: >>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On 10/30/2015 1:57 PM, NGie Cooper wrote: >> Hi Bryan/Simon! >> I tried doing buildworld on powerpc/powerpc with >> -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no >> idea (yet) why it’s trying to compile an x64 object when I specify >> powerpc/powerpc — and more importantly, why is the object not being put >> in obj.powerpc? >> I ran into the same issue on ref11-amd64.freebsd.org when I ran >> “make tinderbox". >> Thanks! >> -NGie >> > > Have you modified any of your local toolchain handling, or skipped > CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > there to be a lot more reports if there was a problem with buildworld > cross compiling. > >> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc >> … >> ===> cddl/usr.sbin/dtrace/tests/common/json (all) >> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && >> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f >> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile >> _RECURSING_PROGS= PROG=tst.usdt.exe ) >> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g >> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json >> -std=gnu99 -fstack-protector-strong-c >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c >> -o tst.usdt.o >> dtrace -C -x nolibs -G -o usdt.o -s >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d >> tst.usdt.o >> dtrace: failed to link script >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >> incorrect ELF machine type for object file: tst.usdt.o >> *** Error code 1 >> >> The problem looks specific to compiling of .d files using dtrace(1). It >> must not have cross-compile support. >> >> The manpage does say: "The D compiler produces programs using the native >> data model of the operating system kernel.". >> >> So these will need to be disabled for non-native builds. >> >> I don't know if it would be possible to build a cross-compile version of >> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. > > In the snippet above, tst.usdt.o is generated by cc, not dtrace(1). > dtrace is complaining that the input file doesn't have the expected > machine type, which seems valid given the file(1) output below. > The example output must be a mistake as they are correct on ref11: ref11-amd64% find /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json -name tst.usdt.o -exec file {} + /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), not stripped [sorry for bad mail client] >> >> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> $ file >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery wrote: ... > The example output must be a mistake as they are correct on ref11: > > ref11-amd64% find > /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > -name tst.usdt.o -exec file {} + > /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not > stripped > /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), > not stripped > /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 > (FreeBSD), not stripped > /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 > (FreeBSD), not stripped > > [sorry for bad mail client] Weird. Ok, I'll do some more digging into this. Thanks for the input! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
NGie Cooper wrote: > I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS > and I ran into this linker issue below. I have no idea (yet) why it’s trying > to compile an x64 object when I specify powerpc/powerpc — and more > importantly, why is the object not being put in obj.powerpc? > I ran into the same issue on ref11-amd64.freebsd.org when I ran “make > tinderbox". Is it possible that the file is left over from a previous build (of amd64?) Does your log show it being built? > dtrace -C -x nolibs -G -o usdt.o -s > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d > tst.usdt.o > dtrace: failed to link script > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > *** Error code 1 > $ find /usr/obj/usr/src/svn/ -name tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o > /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF > 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic in arptimer in r289937
Hiya, Here's a panic from arptimer: (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0x803666b6 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 #2 0x8036614e in db_command (cmd_table=0x0) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 #3 0x80365ee4 in db_command_loop () at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 #4 0x8036897b in db_trap (type=, code=0) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf=) at /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0, eva=) at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829 #7 0x80d34951 in trap (frame=) at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203 #8 0x80d149f7 in calltrap () at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234 #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, file=0x81211b1f "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c", line=205) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261 #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205 #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8, cc=0x81b2d480, direct=0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722 #12 0x80944f87 in softclock (arg=) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851 #13 0x808f7eb6 in intr_event_execute_handlers (p=, ie=0xf800035a6600) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262 #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275 #15 0x808f57a4 in fork_exit (callout=0x808f84a0 , arg=0xf800032c47c0, frame=0xfe022815dac0) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011 #16 0x80d14f2e in fork_trampoline () at /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609 #17 0x in ?? () Current language: auto; currently minimal (kgdb) print *(struct llentry *)c_arg $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8}, r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr = {__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 = 0xf8005ecc4010, __u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned = 110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020 "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00, lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0 , la_hold = 0x0, la_numheld = 0, la_expire = 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0, ln_router = 0, ln_ntick = 0, lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0}, lle_timer = {c_links = {le = {le_next = 0x0, le_prev = 0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x81b2d588}}, c_time = 9066299815445, c_precision = 322122525000, c_arg = 0xf8005ecc4000, c_func = 0x80a246e0 , c_lock = 0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object = { lo_name = 0x8120fbce "lle", lo_flags = 90374144, lo_data = 0, lo_witness = 0xfeb53c80}, rw_lock = 1}} .. (kgdb) print *((struct llentry *)c_arg)->lle_tbl $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242, llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp = 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de, llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry = 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de, llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de, llt_match_prefix = 0xdeadc0dedeadc0de, llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry = 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de, llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry = 0xdeadc0dedeadc0de, llt_free_tbl = 0xdeadc0dedeadc0de} :( Any ideas on where next to look? -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_i386 - Build #1558 - Fixed
FreeBSD_HEAD_i386 - Build #1558 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/console Change summaries: 290224 by imp: The error classification from lower layers is a poor indicator of whether an error is recoverable. Always re-dirty the buffer on errors from write requests. The invalidation we used to do for errors not EIO doesn't need to be done for a device that's really gone, since that's done in a different path. Reviewed by: mckusick@, kib@ 290223 by imp: Rather than using the #define for path names, indirect through a char * variable that could change for different executable types detected. 290222 by imp: Move all the paths into a new path.h to centralize them. 290221 by jhibbits: Print unsigned memory sizes, to handle >2GB RAM on 32-bit powerpc. Sponsored by: Alex Perez/Intertial Computing 290220 by bdrewery: Don't hide stderr when checking ${CC} --version. This can have important debugging information such as 'cc: not found' or 'ccache: error: Could not find compiler "cc" in PATH'. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: > > NGie Cooper wrote: >> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >> and I ran into this linker issue below. I have no idea (yet) why it’s trying >> to compile an x64 object when I specify powerpc/powerpc — and more >> importantly, why is the object not being put in obj.powerpc? >> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make >> tinderbox". > > Is it possible that the file is left over from a previous build (of amd64?) > > Does your log show it being built? > > >> dtrace -C -x nolibs -G -o usdt.o -s >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d >> tst.usdt.o >> dtrace: failed to link script >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >> incorrect ELF machine type for object file: tst.usdt.o >> *** Error code 1 >> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF >> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped Still running into issues on ref11-amd64: cc1: error: unrecognized command line option "-m64" dtrace: failed to compile script /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: Preprocessor failed to process input program --- usdt.h --- *** [usdt.h] Error code 1 Let’s see what happens if I use make buildenv $ env MAKEOBJDIRPREFIX=/scratch/tmp/$USER/obj make buildenv TARGET=mips TARGET_ARCH=mips Entering world for mips:mips $ make -VMAKEOBJDIRPREFIX /scratch/tmp/ngie/obj/mips.mips $ which dtrace /usr/sbin/dtrace Uh… yeah… running the copy from the build host is no bueno. So, that root causes that issue. I’ll file a bug for that (dtrace needs to be built as a bootstrap/cross tool). The -m64 issue is because it’s compiled for amd64 and is running arguments that are only supposed to “work” for x86 platforms (in reality, there’s also no reason why -m32/-m64 need to be passed to ${CC}/${CPP}): 1256 #ifdef illumos 1257 #ifdef __x86 1258 /* 1259 * On x86 systems, __i386 is defined for for 32-bit 1260 * compiles and __amd64 is defined for 64-bit compiles. Unlike SPARC, 1261 * they are defined exclusive of one another (see PSARC 2004/619). 1262 */ 1263 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) { 1264 if (dt_cpp_add_arg(dtp, "-D__amd64") == NULL) 1265 return (set_open_errno(dtp, errp, EDT_NOMEM)); 1266 } else { 1267 if (dt_cpp_add_arg(dtp, "-D__i386") == NULL) 1268 return (set_open_errno(dtp, errp, EDT_NOMEM)); 1269 } 1270 #endif 1271 #else 1272 #if defined(__amd64__) || defined(__i386__) 1273 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) { 1274 if (dt_cpp_add_arg(dtp, "-m64") == NULL) 1275 return (set_open_errno(dtp, errp, EDT_NOMEM)); 1276 } else { 1277 if (dt_cpp_add_arg(dtp, "-m32") == NULL) 1278 return (set_open_errno(dtp, errp, EDT_NOMEM)); 1279 } 1280 #endif 1281 #endif As for why the original issue occurred on my VM (which was the powerpc:powerpc case), I’m not sure yet. I’m working on figuring that out. Thanks! -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"