Scenario: - FreeBSD 14 at 08b9cc316a319fba95af8bb13b262fe0d5526ec3 - Updating ports using portmaster - Updating for armv6 using qemu-user-static in a filesystem holding a complete armv6 installation (using chroot) - Latest ports - WRKDIRPREFIX=/usr/tmp - Executing "portmaster rust-cbindgen-0.20.0_2" Result: - The build fails with "memory allocation of 1879048192 bytes failed" Scenario (continued): - "cd /usr/tmp/ports/devel/rust-cbindgen/work/cbindgen-0.20.0" Result (continued): - This build succeeds (but cannot be used for installing the port because it is placed in a different directory) Expected result: - There should not be this huge memory allocation. Note: - Trying to build this on a real Raspberry Pi B+ exhausts the swap space, leading to a deadlock of the system. - There seems to be another issue on this armv6 machine in that "ulimit datasize" is not honored, not even for a regular user. -- Martin
Created attachment 229450 [details] log file of building rust-cbindgen Attached a logfile created using "script /usr/tmp/cbindgen.log". It shows both the failed portmaster build as well as the successful build using "cargo build --release". It also shows that the second build had to be interrupted because it hung. When continued without parallelism (-j 1), it succeeded. This seems to be the issue described in bug #221185. n.b. The same method allows building rust itself - run using parallelism as long as it does not hang, then continue with "make MAKE_JOBS_NUMBER_LIMIT=1". -- Martin
*** This bug has been marked as a duplicate of bug 257419 ***
Created attachment 229451 [details] armv6 installed ports How can this be a duplicate of bug #257419 if that one is closed as fixed, while using fully updated ports does not allow to build rust-cbindgen? See the attached list of currently installed ports for armv6. Please explain what needs to be done to get this to build.
(In reply to Jan Beich from comment #2) > *** This bug has been marked as a duplicate of bug 257419 *** 259799 is not a duplicate of 257419: the only report in 257419 of: memory allocation of 1879048192 bytes failed was my report of: The following failed for other reasons
Also note that in fact that building using "cargo build" succeeds. Only building using the standard ports build infrastructure fails. I'll reopen this issue. -- Martin
Created attachment 229452 [details] log file of running portmaster to build rust-cbindgen Log file showing failed build when using portmaster to update rust-cbindgen. I re-ran the builds to capture new logs using tee because the script output is hard to read. -- Martin
Created attachment 229453 [details] succeeding build when going into the port build dir and manually running "cargo build --release"
Note regarding the cargo build: I actually ran "cargo build --release -j 1" in order not to trip on the indefinite wait.
My report in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257419 of: The following failed for other reasons . . . memory allocation of 1879048192 bytes failed suggests that the problem is not armv6 specific as it was a armv7 example, built under poudriere. There is some chance that it generaizes to 32-bit archotectures generally (such as 32-bit powerpc variants). (My report of that was, at the time, just indicating what build problems were vs. were-not examples of that submittals problem in my test build. I did not submit it as a separate issue.)
(In reply to Martin Birgmeier from comment #8) You may want to edit the bugzilla submittal's summary line to have the: "-j 1" as well.
Thank you Mark for your inputs, I added the "-j 1". But it is not the root cause of the problem, because if I build the port using "make MAKE_JOBS_NUMBER_LIMIT=1" (in /usr/ports/devel/rust-cbindgen), it still fails with the same allocation error. -- Martin
(In reply to Martin Birgmeier from comment #3) > rust-1.56.0 OK, this is valid. Maybe bug 257419 resurfaced with slightly different error. Did you check how many other USES=cargo (Rust-based) ports are affected? > Please explain what needs to be done to get this to build. Debugging "rust" or "cargo" itself is outside of scope for gecko@. Besides, www/firefox isn't supported on armv6 and armv7 due to NEON detection mess upstream.
(In reply to Martin Birgmeier from comment #0) I just see that there was a crucial piece of information missing in the original report: Scenario (continued): - "cd /usr/tmp/ports/devel/rust-cbindgen/work/cbindgen-0.20.0" - "cargo build --release -j 1" <=============== this is the missing piece of information To be even more precise, I first started the build using just "cargo build --release", and then when it hung, continued with "-j 1". For this latter issue, see bug #254694. When I submitted that one I did not yet know that I could work around the problem by disabling parallel building. -- Martin
(In reply to Jan Beich from comment #12) Hi Jan, of the ports I am using only rust-cbindgen, and specifically tempfile in it, consistently fails. It is very strange because tempfile actually is just a small piece of code. -- Martin
Hi Jan, Regarding the hang issue (not the topic of this PR), my PR #254694 got marked as a duplicate of #221185, and in that one Kyle Evans writes "_umtx_op handling has been the bane of my existence...". Am I correct in assuming that what he is describing there is the reason for the hang? And will there ever be the change he is hinting at? I probably should ask him directly. :-) -- Martin
(In reply to Martin Birgmeier from comment #11) > But it is not the root cause of the problem, because if I > build the port using "make MAKE_JOBS_NUMBER_LIMIT=1" (in > /usr/ports/devel/rust-cbindgen), it still fails with the > same allocation error. MAKE_JOBS_NUMBER_LIMIT only directly limits make and rust builds do other parallel actvity not under make's control, including via some scripting as I remember. If I remember right, some extra parallelism was a fairly recent change. I'll see if I can find my old notes that were related.
(In reply to Martin Birgmeier from comment #15) That hangup is a qemu problem, not in any way specific to your activity. But I do not use qemu and my tests that got this the huge size error were on a Cortext-A72 system that was targeting armv7 in poudriere: a form on native execution, alothough not on a system that was limited to armv7. So there are two separate issues.
(In reply to Mark Millard from comment #16) Actually, the old notes were about www/chromium builds having extra sources of parallelism, not rust itself. rust may or may not, I do not know.
(In reply to Martin Birgmeier from comment #14) > Hi Jan, of the ports I am using only rust-cbindgen, and specifically tempfile > in it, consistently fails. tempfile appears in around 80 USES=cargo ports. According to attachment 229451 [details] you don't have many Rust-based ports devel/rust-cbindgen (USES=cargo + tempfile) graphics/librsvg2-rust (vendored + tempfile) lang/spidermonkey78 (vendored + tempfile) Please, try more USES=cargo ports e.g., dns/dog, sysutils/lsd, textproc/sd. All of these examples use tempfile crate, to get the full list try $ git grep -l tempfile- | sed '/distinfo/d; /files/d; s,/Makefile,,; s/\.crates//'
(In reply to Jan Beich from comment #19) In a somewhat older ports context I've started a poudriere build of such for armv7 under main [so: 14] where rust is at 1.55 . FYI: # ~/fbsd-based-on-what-commit.sh branch: main merge-base: faf17873c10627379554b4c5f7a66539b347f221 merge-base: CommitDate: 2021-10-23 21:38:18 +0000 faf17873c106 (HEAD -> main, freebsd/main, freebsd/HEAD) lang/gnatdroid-binutils: Add CPE information n563214 (--first-parent --count for merge-base) # wc ~/rust-tmpfile-crate-ports.txt 77 77 1221 /usr/home/root/rust-tmpfile-crate-ports.txt . . . that was after deleting the line: lang/gleam.deps that poudriere rejected when I first tried. . . . [00:00:12] Ignoring devel/py-maturin . . . [00:00:13] Ignoring graphics/rx . . . [00:00:14] Ignoring devel/sccache . . . [00:00:16] Ignoring net/krill . . . [00:00:16] Ignoring net/routinator . . . [00:00:18] Ignoring games/veloren . . . [00:00:20] Ignoring sysutils/zellij . . . . . . Building 507 packages using 16 builders I'll later report on failures.
(In reply to Mark Millard from comment #20) Looks like lang/gleam.deps should have been just: lang/gleam so I can try that as well, after the on-going builds finish. (The .deps is from there being a Makfile.deps with the matching text, where the Makefile includes the the Makefile.deps file.)
Here a data point from building rust-cbindgen natively on the RPI-B, while building tempfile: last pid: 1455; load averages: 2.15, 2.06, 1.79 up 0+01:17:25 09:31:20 35 processes: 3 running, 32 sleeping CPU: 60.9% user, 0.0% nice, 25.9% system, 6.0% interrupt, 7.1% idle Mem: 268M Active, 26M Inact, 33M Laundry, 88M Wired, 51M Buf, 9768K Free Swap: 1701M Total, 688M Used, 1013M Free, 40% Inuse, 2692K In, 1024K Out PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1358 root 2 56 0 1101M 301M uwait 4:17 57.96% rustc 1455 root 1 50 0 55M 26M RUN 0:01 22.16% pkg-static 1253 root 1 40 0 13M 2980K select 0:08 2.00% xterm 1226 root 1 40 0 6848K 1696K RUN 0:38 1.91% top 1155 root 1 40 0 8284K 2472K RUN 0:15 1.83% tmux 1138 root 1 40 0 15M 2156K select 0:29 1.14% xterm 1204 root 3 40 0 28M 1568K uwait 0:15 0.42% cargo 708 root 1 40 0 10M 2892K select 0:03 0.19% wpa_supplica 1123 root 1 40 0 13M 2028K select 0:08 0.00% xterm 1156 root 1 16 0 11M 0B pause 0:04 0.00% <zsh> 1269 root 1 16 0 8944K 1164K pause 0:04 0.00% zsh 1141 root 1 16 0 8892K 0B pause 0:03 0.00% <zsh> 1124 root 1 16 0 8332K 0B pause 0:03 0.00% <zsh> 1254 root 1 16 0 8332K 0B pause 0:03 0.00% <zsh> 1187 root 1 8 0 6112K 0B wait 0:02 0.00% <make> 1136 root 1 40 0 8684K 1568K select 0:02 0.00% xload The size of the rustc process approximately doubles every few minutes (on this small machine, it is running very slowly). A few minutes after this it will have a size of more than 1900M, and at that point the machine freezes (the OOM killer kills a lot of other processes but ultimately does not save the machine; it has to be power cycled). I am still building sysutils/lsd using the qemu-arm-static emulation, but it seems that it has already passed tempfile there without a hitch. We will see. -- Martin
Building sysutils/lsd using qemu-user-static just completed successfully - including the "tempfile" in it. Very mysterious! -- Martin n.b. Because of the "qemu hang" issue, the actual sequence used to build this was: - portmaster sysutils/lsd - (wait until CPU usage drops to 0%) - ^C - MAKE_JOBS_NUMBER_LIMIT=1 portmaster sysutils/lsd But "tempfile" already compiled successfully before the hang.
(In reply to Mark Millard from comment #21) Before the system locked up (other than via being able to escape into ddb), the attempt did get an example of: memory allocation of 1879048192 bytes failed in/for: net/oha that was saved to its log file for the build before the forced reboot was done (hours after the hangup started). The few other error logs had other types of errors, such as mismatched types or fetch failures. For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400040 1400040 # poudriere jail -jmain-CA7 -i Jail name: main-CA7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud Jail fs: Jail updated: 2021-06-27 17:58:33 Jail pkgbase: disabled 16 cortex-A72 cores, 64 GiBytes RAM, root on ZFS, 251904Mi swap, USE_TMPFS=all in use.
(In reply to Mark Millard from comment #24) From the log file, the create failing was not tempfile but trust-dns-proto : warning: `h2` (lib) generated 5 warnings memory allocation of 1879048192 bytes failed warning: `hyper` (lib) generated 2 warnings error: could not compile `trust-dns-proto` Caused by: process didn't exit successfully: `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=trust_dns_proto CARGO_MANIFEST_DIR=/wrkdirs/usr/ports/net/oha/work/oha-0.4.4/cargo-crates/trust-dns-proto-0.19.6 CARGO_PKG_AUTHORS='Benjamin Fry <benjaminfry@me.com>' CARGO_PKG_DESCRIPTION='Trust-DNS is a safe and secure DNS library. This is the foundational DNS protocol library for all Trust-DNS projects. ' CARGO_PKG_HOMEPAGE='http://www.trust-dns.org/index.html' CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=trust-dns-proto CARGO_PKG_REPOSITORY='https://github.com/bluejekyll/trust-dns' CARGO_PKG_VERSION=0.19.6 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=19 CARGO_PKG_VERSION_PATCH=6 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/wrkdirs/usr/ports/net/oha/work/target/debug/deps:/usr/local/lib' /usr/local/bin/rustc --crate-name trust_dns_proto --edition=2018 /wrkdirs/usr/ports/net/oha/work/oha-0.4.4/cargo-crates/trust-dns-proto-0.19.6/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="tokio"' --cfg 'feature="tokio-runtime"' -C metadata=4bcd075796cca551 -C extra-filename=-4bcd075796cca551 --out-dir /wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps --target armv7-unknown-freebsd -C linker=cc -L dependency=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps -L dependency=/wrkdirs/usr/ports/net/oha/work/target/debug/deps --extern async_trait=/wrkdirs/usr/ports/net/oha/work/target/debug/deps/libasync_trait-f9bfd9bd3eb73048.so --extern backtrace=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libbacktrace-bad0df924f470b10.rmeta --extern enum_as_inner=/wrkdirs/usr/ports/net/oha/work/target/debug/deps/libenum_as_inner-5183ff722da443b4.so --extern futures=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libfutures-c757a29d00b90671.rmeta --extern idna=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libidna-10945b39bd2c0932.rmeta --extern lazy_static=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/liblazy_static-204e38aa80232e66.rmeta --extern log=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/liblog-d1654c00967bfa0d.rmeta --extern rand=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/librand-084761925f0728b5.rmeta --extern smallvec=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libsmallvec-3e2f8e6b0f76a888.rmeta --extern thiserror=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libthiserror-4f299f14a481f73a.rmeta --extern tokio=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/libtokio-721392aad331faa3.rmeta --extern url=/wrkdirs/usr/ports/net/oha/work/target/armv7-unknown-freebsd/debug/deps/liburl-08c3207afa1b47e5.rmeta --cap-lints warn -C target-cpu=cortex-a7 -C link-arg=-fstack-protector-strong` (signal: 6, SIGABRT: process abort signal) *** Error code 101
net/oha already uses tempfile-3.2.0, whereas devel/rust-cbindgen uses tempfile-3.1.0. Maybe the issue comes from using outdated crate versions for the various components? And maybe it is one of the components coming before tempfile (or trust-dns-proto) which result in this memory allocation error? -- Martin
(In reply to Martin Birgmeier from comment #26) Remember that my test context goes back to /usr/ports as of: # ~/fbsd-based-on-what-commit.sh branch: main merge-base: faf17873c10627379554b4c5f7a66539b347f221 merge-base: CommitDate: 2021-10-23 21:38:18 +0000 faf17873c106 (HEAD -> main, freebsd/main, freebsd/HEAD) lang/gnatdroid-binutils: Add CPE information n563214 (--first-parent --count for merge-base) It turns out that a rustc.core file was generated and gdb reports: Core was generated by `/usr/local/bin/rustc --crate-name trust_dns_proto --edition=2018 /wrkdirs/usr/po'. but the rustc in my environment is not a debug build and I do not get a reasoonable backtrace to report. (I do not now that a 32-bit debug-build of rustc is even possible. I'm not even sure for 64-bit aarch64.)
(In reply to Mark Millard from comment #27) Note: I've replicated the oha failure with USE_TMPFS="data" in use, which avoids large tmpfs memory use for the poudriere-devel use (poudriere bulk command).
(In reply to Mark Millard from comment #28) I'm getting various builds that are generating multi-GiByte log files (and growing) that have lines like: thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:559:5 stack backtrace: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.55.0 running on armv7-unknown-freebsd note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=cc --crate-type lib note: some of the compiler flags provided by cargo are hidden query stack during panic: #0 [trimmed_def_paths] calculating trimmed def paths #1 [lint_mod] linting module `transitions` #2 [analysis] running analysis passes on this crate end of query stack thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 stack backtrace: 0: 0x4710076c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h4428caffcb182c5b 1: 0x471c9d00 - core::fmt::write::h91f4a7678561fd61 2: 0x470e2180 - <unknown> 3: 0x470ebd40 - <unknown> 4: 0x470eb824 - <unknown> 5: 0x41ed4848 - <unknown> 6: 0x470ec690 - std::panicking::rust_panic_with_hook::h6bc4b7e83060df25 7: 0x47100f0c - <unknown> 8: 0x47100900 - <unknown> 9: 0x470ec374 - <unknown> . . . 65: 0x470ee71c - <unknown> 66: 0x401361bc - <unknown> 67: 0x40135cd8 - pthread_create 68: 0x40138b9c - pthread_peekjoin_np 69: 0x40138b9c - pthread_peekjoin_np 70: 0x40138b9c - pthread_peekjoin_np 71: 0x40138b9c - pthread_peekjoin_np 72: 0x40138b9c - pthread_peekjoin_np 73: 0x40138b9c - pthread_peekjoin_np . . . massive repitition of pthread_peekjoin_np lines . . .
(In reply to Mark Millard from comment #29) Example huge log files: -rw-r--r-- 1 root wheel 4809169741 Nov 12 20:34:18 2021 rust-cbindgen-0.20.0_2.log -rw-r--r-- 1 root wheel 4761300902 Nov 12 20:36:15 2021 findomain-5.0.0_2.log -rw-r--r-- 1 root wheel 4759612674 Nov 12 20:35:53 2021 ripgrep-all-0.9.6_2.log -rw-r--r-- 1 root wheel 4752672816 Nov 12 20:34:18 2021 cargo-c-0.9.4.log -rw-r--r-- 1 root wheel 4717742587 Nov 12 20:35:22 2021 rsfetch-2.0.0_16.log -rw-r--r-- 1 root wheel 4693379058 Nov 12 20:35:22 2021 mdbook-0.4.13.log -rw-r--r-- 1 root wheel 4692245209 Nov 12 20:37:54 2021 angle-grinder-0.18.0.log -rw-r--r-- 1 root wheel 4671542751 Nov 12 20:35:53 2021 sd-0.7.6_11.log -rw-r--r-- 1 root wheel 4646613562 Nov 12 20:35:53 2021 tealdeer-1.4.1_10.log -rw-r--r-- 1 root wheel 4539995494 Nov 12 23:20:43 2021 ncspot-0.6.0_5.log -rw-r--r-- 1 root wheel 4310178735 Nov 12 23:24:08 2021 sequoia-0.19.0_9.log -rw-r--r-- 1 root wheel 4159557699 Nov 12 23:25:23 2021 vector-0.10.0_9.log -rw-r--r-- 1 root wheel 3468604589 Nov 12 23:25:26 2021 cargo-generate-0.9.0_2.log -rw-r--r-- 1 root wheel 3454209539 Nov 12 20:34:18 2021 grcov-0.8.2_2.log -rw-r--r-- 1 root wheel 2915451188 Nov 12 20:35:22 2021 lychee-0.7.1.log -rw-r--r-- 1 root wheel 1254194156 Nov 12 20:47:59 2021 zola-0.14.1_2.log
(In reply to Mark Millard from comment #30) I have confirmed that on a Cortex-A7 (armv7) system, I also get (for example): . . . thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:559:5 stack backtrace: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.55.0 running on armv7-unknown-freebsd note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=cc -C target-cpu=cortex-a7 -C link-arg=-fstack-protector-strong --crate-type lib note: some of the compiler flags provided by cargo are hidden query stack during panic: #0 [trimmed_def_paths] calculating trimmed def paths #1 [lint_mod] linting module `file` #2 [analysis] running analysis passes on this crate end of query stack thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 stack backtrace: 0: 0x2750076c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h4428caffcb182c5b 1: 0x275c9d00 - core::fmt::write::h91f4a7678561fd61 . . . 49: 0x274ee71c - <unknown> 50: 0x2783b1bc - <unknown> 51: 0x2783acd8 - pthread_create 52: 0x2783db9c - pthread_peekjoin_np 53: 0x2783db9c - pthread_peekjoin_np 54: 0x2783db9c - pthread_peekjoin_np 55: 0x2783db9c - pthread_peekjoin_np . . . pthread_peekjoin_np lines repating (but for the prefix) . . . So the issue for this is not tied to COMPATFREEBSD32 or the like.
(In reply to Mark Millard from comment #31) In the Cortext-A72 environment I tried just lang/gleam and the poudriere based build finished just fine.
(In reply to Mark Millard from comment #32) Thank you for all the testing you are doing! Did you check whether simply running "cargo build --release" in the configured build area is working? - Because in my setup, just doing "make" in /usr/ports/devel/rust-cbindgen fails with the allocation error, but executing "make configure ; cd "${WRKDIRPREFIX}/`/bin/pwd`/work/cbindgen-0.20.0" ; cargo build --release" succeeds (but leaves no usable result for the port build process because the artifacts built are not placed in the separate build directory). There seems to be some issue in how cargo is invoked for the build phase of a port - maybe it is the way the separate build directory is set. -- Martin
(In reply to Martin Birgmeier from comment #33) I'm now in the middle of doing a round of FreeBSD vintage updates in my environments. It will be a while before I do any more experiments in this area. I've not yet decided if I will also update my /usr/ports/ vintage once FreeBSD has been updated.
(In reply to Mark Millard from comment #34) There have been complications during my update attempt and I'm investigating other issues for now. It may be days before I get back to this. (Builds are involved that take 24 hr or so each try of the group of them.)
(In reply to Mark Millard from comment #35) I've got things updated and past the issues that I'd run into. # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 (The other systems are based on the same source.) The following is based on a chroot to an armv7 system on a Cortex-A72 (so: aarch64) system. I established an updated rust: 1.56 in poudriere jail main-CA7 via poudriere-devel. I then added: # git -C /usr/ports diff /usr/ports/devel/rust-cbindgen/Makefile diff --git a/devel/rust-cbindgen/Makefile b/devel/rust-cbindgen/Makefile index 79d4335cf986..df7c504116c5 100644 --- a/devel/rust-cbindgen/Makefile +++ b/devel/rust-cbindgen/Makefile @@ -67,4 +67,8 @@ CARGO_CRATES= ansi_term-0.11.0 \ winapi-i686-pc-windows-gnu-0.4.0 \ winapi-x86_64-pc-windows-gnu-0.4.0 +.if ${ARCH:Marmv?} +MAKE_JOBS_UNSAFE= +.endif + .include <bsd.port.mk> and attempted: poudriere bulk -j main-CA7 -w devel/rust-cbindgen (This does not require any more ports than required for rust itself.) The result was a "SIGSEGV: invalid memory reference" : error: could not compile `tempfile` Caused by: process didn't exit successfully: `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=tempfile CARGO_MANIFEST_DIR=/wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/cargo-crates/tempfile-3.1.0 CARGO_PKG_AUTHORS='Steven Allen <steven@stebalien.com>:The Rust Project Developers:Ashley Mannix <ashleymannix@live.com.au>:Jason White <jasonaw0@gmail.com>' CARGO_PKG_DESCRIPTION='A library for managing temporary files and directories.' CARGO_PKG_HOMEPAGE='http://stebalien.com/projects/tempfile-rs' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=tempfile CARGO_PKG_REPOSITORY='https://github.com/Stebalien/tempfile' CARGO_PKG_VERSION=3.1.0 CARGO_PKG_VERSION_MAJOR=3 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/debug/deps:/usr/local/lib' /usr/local/bin/rustc --crate-name tempfile --edition=2018 /wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/cargo-crates/tempfile-3.1.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=8c80968e1c70792f -C extra-filename=-8c80968e1c70792f --out-dir /wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps --target armv7-unknown-freebsd -C linker=cc -L dependency=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps -L dependency=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/debug/deps --extern cfg_if=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/libcfg_if-bcb77f88a4cb1033.rmeta --extern libc=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/liblibc-9cfeb93970e2f28b.rmeta --extern rand=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/librand-521a6a5a702772ce.rmeta --extern remove_dir_all=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/libremove_dir_all-eb5202f50395c473.rmeta --cap-lints warn -C target-cpu=cortex-a7 -C link-arg=-fstack-protector-strong` (signal: 11, SIGSEGV: invalid memory reference) *** Error code 101 I'll see if I can build rust with debug symbols in order to get a useful backtrace from a .core file --but I doubt that I'll be able to build such in a armv7-ish context. For reference: My variant of top reported for the devel/rust-cbindgen time frame. last pid: . . .; load averages: . . . MaxObs: 3.51, 1.20, 0.74 I expect that the numbers would be a lot larger if the MAKE_JOBS_UNSAFE= had not worked: the system has 16 cores.
(In reply to Mark Millard from comment #36) Yea, attempting to have debug symbols building rust 1.56 in a armv7 context got: LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o bin/llvm-ar /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/us r/lib --color-diagnostics -z origin -O3 --gc-sections tools/llvm-ar/CMakeFiles/llvm-ar.dir/llvm-ar.cpp.o -rpath $ORIGIN/../lib lib/libLLVMAArch64AsmParser.a lib/libLLVMARMAsmParser.a lib/libLLVMBPFAsm Parser.a lib/libLLVMHexagonAsmParser.a lib/libLLVMMSP430AsmParser.a lib/libLLVMMipsAsmParser.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMRISCVAsmParser.a lib/libLLVMSparcAsmParser.a lib/libLLVMSystemZA smParser.a lib/libLLVMWebAssemblyAsmParser.a lib/libLLVMX86AsmParser.a lib/libLLVMAVRAsmParser.a lib/libLLVMAArch64Desc.a lib/libLLVMARMDesc.a lib/libLLVMBPFDesc.a lib/libLLVMHexagonDesc.a lib/libLLVM MSP430Desc.a lib/libLLVMMipsDesc.a lib/libLLVMNVPTXDesc.a lib/libLLVMPowerPCDesc.a lib/libLLVMRISCVDesc.a lib/libLLVMSparcDesc.a lib/libLLVMSystemZDesc.a lib/libLLVMWebAssemblyDesc.a lib/libLLVMX86Des c.a lib/libLLVMAVRDesc.a lib/libLLVMAArch64Info.a lib/libLLVMARMInfo.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonInfo.a lib/libLLVMMSP430Info.a lib/libLLVMMipsInfo.a lib/libLLVMNVPTXInfo.a lib/libLLVMPow erPCInfo.a lib/libLLVMRISCVInfo.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZInfo.a lib/libLLVMWebAssemblyInfo.a lib/libLLVMX86Info.a lib/libLLVMAVRInfo.a lib/libLLVMBinaryFormat.a lib/libLLVMCore.a lib /libLLVMDlltoolDriver.a lib/libLLVMLibDriver.a lib/libLLVMObject.a lib/libLLVMSupport.a -lpthread lib/libLLVMAArch64Utils.a lib/libLLVMARMUtils.a lib/libLLVMMCDisassembler.a lib/libLLVMWebAssemblyUtil s.a lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis. a lib/libLLVMProfileData.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMTextAPI.a lib/libLLVMOption.a lib/libLLVMBitReader.a lib/libLLVMCore.a li b/libLLVMBinaryFormat.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libLLVMSupport.a -lrt -lexecinfo -lpthread -lm /usr/lib/libz.so lib/libLLVMDemangle.a -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o #0 0x00d12370 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/bin/ld+0xd12370) #1 0x00d1028c llvm::sys::RunSignalHandlers() (/usr/bin/ld+0xd1028c) #2 0x00d12d24 SignalHandler(int) (/usr/bin/ld+0xd12d24) #3 0x41dbf484 (/lib/libthr.so.3+0x27484) c++: error: unable to execute command: Abort trap (core dumped) c++: error: linker command failed due to signal (use -v to see invocation) So much for that idea.
(In reply to Mark Millard from comment #37) "debug symbols" was the wrong phrase: "debug information" would have been better.
(In reply to Mark Millard from comment #36) The try in comment 36 was under main-CA7 jail. I tried under the 13_0R-CA7 jail (so: 13.0-RELEASE-p5 world) (without rustc having been stripped but having no debug information) and the failure was more like before but it did stop thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:559:5 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic 3: alloc::raw_vec::capacity_overflow 4: alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle 5: std::backtrace::Backtrace::create::{{closure}} 6: std::backtrace_rs::backtrace::libunwind::trace::trace_fn 7: _Unwind_Backtrace 8: std::backtrace::Backtrace::create 9: std::backtrace::Backtrace::force_capture 10: <unknown> . . . 42: <unknown> 43: std::sys::unix::thread::Thread::new::thread_start 44: <unknown> 45: pthread_create 46: pthread_peekjoin_np . . . 91: pthread_peekjoin_np note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.56.0 running on armv7-unknown-freebsd note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=cc -C target-cpu=cortex-a7 -C link-arg=-fstack-protector-strong --crate-type lib note: some of the compiler flags provided by cargo are hidden query stack during panic: #0 [trimmed_def_paths] calculating trimmed def paths #1 [lint_mod] linting module `file` #2 [analysis] running analysis passes on this crate end of query stack error: could not compile `tempfile` Caused by: process didn't exit successfully: `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=tempfile CARGO_MANIFEST_DIR=/wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/cargo-crates/tempfile-3.1.0 CARGO_PKG_AUTHORS='Steven Allen <steven@stebalien.com>:The Rust Project Developers:Ashley Mannix <ashleymannix@live.com.au>:Jason White <jasonaw0@gmail.com>' CARGO_PKG_DESCRIPTION='A library for managing temporary files and directories.' CARGO_PKG_HOMEPAGE='http://stebalien.com/projects/tempfile-rs' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=tempfile CARGO_PKG_REPOSITORY='https://github.com/Stebalien/tempfile' CARGO_PKG_VERSION=3.1.0 CARGO_PKG_VERSION_MAJOR=3 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/debug/deps:/usr/local/lib' /usr/local/bin/rustc --crate-name tempfile --edition=2018 /wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/cargo-crates/tempfile-3.1.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=8c80968e1c70792f -C extra-filename=-8c80968e1c70792f --out-dir /wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps --target armv7-unknown-freebsd -C linker=cc -L dependency=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps -L dependency=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/debug/deps --extern cfg_if=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/libcfg_if-bcb77f88a4cb1033.rmeta --extern libc=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/liblibc-9cfeb93970e2f28b.rmeta --extern rand=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/librand-521a6a5a702772ce.rmeta --extern remove_dir_all=/wrkdirs/usr/ports/devel/rust-cbindgen/work/target/armv7-unknown-freebsd/debug/deps/libremove_dir_all-eb5202f50395c473.rmeta --cap-lints warn -C target-cpu=cortex-a7 -C link-arg=-fstack-protector-strong` (signal: 5, SIGTRAP: trace/breakpoint trap) *** Error code 101 Notabily in this context it reported SIGTRAP instead of the SIGSEGV that main-CA7 reported. Also notable is that the capacity-overflow happened during the attempt to do a backtrace that had already been initiated: Nested problems? (Possibly SIGSEGV was first?)
(In reply to Mark Millard from comment #39) > Also notable is that the capacity-overflow happened during the attempt to > do a backtrace that had already been initiated: Nested problems? (Possibly > SIGSEGV was first?) Try disabling backtrace's libunwind backend like in https://github.com/t6/freebsd-ports/commit/b9877a1f441d51e42aca894cf887a3717c6a6e1a.patch (just change "riscv64" to "arm" I guess and make sure to move patch-library_backtrace_src_backtrace_mod.rs to lang/rust/files/).
(In reply to Mark Millard from comment #36) I finally got a no-strip (but no debug information) environment set up where I can look at the main [so: 14] based build failure via a backtrace. This is still an optimiazed build so there could be oddities in the backtrace but it should be useful:. It looks like: rustc_errors::Handler::delay_good_path_bug () from /usr/local/lib/librustc_driver-a196dfc434d07325.so initiated the backtrace that is later problematical. gdb reports: Core was generated by `/usr/local/bin/rustc --crate-name tempfile --edition=2018 /wrkdirs/usr/ports/dev'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 _Unwind_VRS_Pop (context=0xbfff5b80, regclass=_UVRSC_CORE, discriminator=18432, representation=_UVRSD_UINT32) at /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 915 uint32_t value = *sp++; [Current thread is 1 (LWP 710038)] (gdb) bt #0 _Unwind_VRS_Pop (context=0xbfff5b80, regclass=_UVRSC_CORE, discriminator=18432, representation=_UVRSD_UINT32) at /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 #1 _Unwind_VRS_Interpret (context=0xbfff5b80, data=<optimized out>, offset=4, len=4) at /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:281 #2 0x400c83e0 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm>::stepWithEHABI (this=0xbfff5b80) at /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:921 #3 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm>::step (this=0xbfff5b80) at /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2094 #4 0x400c7134 in (anonymous namespace)::unwindOneFrame (state=<optimized out>, ucbp=0xbfff59d8, context=0xbfff5b80) at /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:190 #5 0x400c7708 in _Unwind_Backtrace (callback=0x47346bc0 <std::backtrace_rs::backtrace::libunwind::trace::trace_fn>, ref=0xbfff5d58) at /usr/main-src/contrib/llvm-project/libunwind/src/UnwindLevel1-gcc-ext.c:156 #6 0x47311b58 in std::backtrace::Backtrace::create () from /usr/local/lib/libstd-21f5f79d0bba7291.so #7 0x47311ac8 in std::backtrace::Backtrace::force_capture () from /usr/local/lib/libstd-21f5f79d0bba7291.so #8 0x46c61f28 in rustc_errors::Handler::delay_good_path_bug () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #9 0x46a33998 in rustc_middle::ty::print::pretty::trimmed_def_paths::h696a2e73b4fe3316 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #10 0x4591ef34 in rustc_query_system::query::plumbing::get_query_impl::h97f9a3ac217b06d6 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #11 0x45d45a2c in <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::trimmed_def_paths () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #12 0x46a1acec in <rustc_middle::ty::print::pretty::FmtPrinter<F> as rustc_middle::ty::print::Printer>::print_def_path () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #13 0x4695cef8 in rustc_middle::ty::print::pretty::<impl rustc_middle::ty::context::TyCtxt>::def_path_str_with_substs () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #14 0x4695cd68 in rustc_middle::ty::print::pretty::<impl rustc_middle::ty::context::TyCtxt>::def_path_str () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #15 0x465fc36c in core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hbd67d6eb15125f94 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #16 0x4692fd68 in rustc_middle::lint::struct_lint_level::struct_lint_level_impl () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #17 0x466039c8 in <rustc_lint::unused::UnusedResults as rustc_lint::passes::LateLintPass>::check_stmt () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #18 0x4659a8d8 in <rustc_lint::late::LateContextAndPass<T> as rustc_hir::intravisit::Visitor>::visit_stmt () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #19 0x465b5920 in rustc_hir::intravisit::walk_expr () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #20 0x4659a380 in <rustc_lint::late::LateContextAndPass<T> as rustc_hir::intravisit::Visitor>::visit_nested_body () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #21 0x4659ac04 in <rustc_lint::late::LateContextAndPass<T> as rustc_hir::intravisit::Visitor>::visit_fn () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #22 0x465aaff0 in rustc_hir::intravisit::walk_impl_item () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #23 0x46598a98 in rustc_hir::intravisit::Visitor::visit_nested_impl_item () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #24 0x465b7f8c in rustc_hir::intravisit::walk_item () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #25 0x46597d8c in rustc_hir::intravisit::Visitor::visit_nested_item () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #26 0x4659c298 in rustc_lint::late::late_lint_mod () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #27 0x45961444 in rustc_query_system::query::plumbing::get_query_impl::he2b46ba21cb31bb4 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #28 0x45d3ed78 in <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::lint_mod () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #29 0x421a844c in rustc_data_structures::sync::join () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #30 0x42178e7c in <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #31 0x421a7224 in rustc_session::utils::<impl rustc_session::session::Session>::time () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #32 0x420fe6c8 in rustc_interface::passes::analysis () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #33 0x458bb1c4 in rustc_query_system::query::plumbing::get_query_impl::h01ade962adc0e126 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #34 0x45d3b254 in <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #35 0x420368e8 in rustc_interface::passes::QueryContext::enter () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #36 0x4201397c in rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #37 0x41fd1540 in rustc_span::with_source_map () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #38 0x42011e48 in scoped_tls::ScopedKey<T>::set () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #39 0x41fdbca0 in std::sys_common::backtrace::__rust_begin_short_backtrace::hdc54cbe6eb1f58a5 () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #40 0x41fccce8 in core::ops::function::FnOnce::call_once{{vtable.shim}} () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #41 0x4730bfb4 in std::sys::unix::thread::Thread::new::thread_start () from /usr/local/lib/libstd-21f5f79d0bba7291.so #42 0x401371ac in thread_start (curthread=0x40073a00) at /usr/main-src/lib/libthr/thread/thr_create.c:292 #43 0x40136cdc in _pthread_create (thread=0xffffb0b8, attr=<optimized out>, start_routine=<optimized out>, arg=<optimized out>) at /usr/main-src/lib/libthr/thread/thr_create.c:187 #44 0x40139a4c in _thr_umutex_unlock2 (mtx=0x0, id=11, defer=0x0) at /usr/main-src/lib/libthr/thread/thr_umtx.h:160 #45 _thr_umutex_unlock (mtx=0x0, id=11) at /usr/main-src/lib/libthr/thread/thr_umtx.h:183Backtrace stopped: Cannot access memory at address 0x4 (gdb) info threads Id Target Id Frame * 1 LWP 710038 _Unwind_VRS_Pop (context=0xbfff5b80, regclass=_UVRSC_CORE, discriminator=18432, representation=_UVRSD_UINT32) at /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 2 LWP 296951 _umtx_op () at _umtx_op.S:4 (gdb) thread 2 [Switching to thread 2 (LWP 296951)] #0 _umtx_op () at _umtx_op.S:4 4 _umtx_op.S: No such file or directory. (gdb) bt #0 _umtx_op () at _umtx_op.S:4 #1 0x40147d64 in _umtx_op_err (obj=0x4, op=2, val=1, uaddr=0x0, uaddr2=<optimized out>) at /usr/main-src/lib/libthr/thread/thr_umtx.c:39 #2 _thr_umtx_wait (mtx=0x4, id=1, timeout=<optimized out>) at /usr/main-src/lib/libthr/thread/thr_umtx.c:201 #3 0x40139868 in join_common (pthread=0x40073a00, thread_return=0x0, abstime=0x0, peek=<optimized out>) at /usr/main-src/lib/libthr/thread/thr_join.c:147 #4 0x4730c190 in std::sys::unix::thread::Thread::join () from /usr/local/lib/libstd-21f5f79d0bba7291.so #5 0x41fcc3d8 in std::thread::JoinHandle<T>::join () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #6 0x420141c4 in rustc_interface::interface::run_compiler () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #7 0x41fc3e0c in rustc_driver::RunCompiler::run () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #8 0x41fda1c4 in <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #9 0x41fca500 in rustc_driver::main () from /usr/local/lib/librustc_driver-a196dfc434d07325.so #10 0x00022928 in rustc_main::main () #11 0x00022970 in std::sys_common::backtrace::__rust_begin_short_backtrace () #12 0x00022980 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hf3c8c073b90c923c () #13 0x47326924 in std::rt::lang_start_internal () from /usr/local/lib/libstd-21f5f79d0bba7291.so #14 0x00022958 in main ()
(In reply to Mark Millard from comment #41) Looks like: rustc_errors::Handler::delay_good_path_bug was initiated by ( quoting https://doc.rust-lang.org/stable/nightly-rustc/rustc_middle/ty/print/pretty/fn.trimmed_def_paths.html ): Function rustc_middle::ty::print::pretty::trimmed_def_pathsCopy item path [−][src] fn trimmed_def_paths(tcx: TyCtxt<'_>, (): ()) -> FxHashMap<DefId, Symbol> The purpose of this function is to collect public symbols names that are unique across all crates in the build. Later, when printing about types we can use those names instead of the full exported path to them. So essentially, if a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening std::vec::Vec to just Vec, as long as there is no other Vec importable anywhere. The implementation uses similar import discovery logic to that of ‘use’ suggestions.
(In reply to Tobias Kortkamp from comment #40) that works, thanks.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=237b36fa2e73986dc19284686e80a47cb329bb6f commit 237b36fa2e73986dc19284686e80a47cb329bb6f Author: Tobias Kortkamp <tobik@FreeBSD.org> AuthorDate: 2021-11-30 12:54:55 +0000 Commit: Tobias Kortkamp <tobik@FreeBSD.org> CommitDate: 2021-12-05 12:35:41 +0000 lang/rust: Update to 1.57.0 - Unbreak build with LibreSSL 3.4.x [0] - Disable backtrace's libunwind backend on armv* since it or libunwind in base seem to be buggy and cause rustc to crash when building some consumers [1] - Follow rust-nightly in d5f09dc31fcfdb77b69c86b9093bf67ec67653d9 and reenable hardlinks in the build Changes: https://blog.rust-lang.org/2021/12/02/Rust-1.57.0.html PR: 259738 [0] PR: 259799 [1] PR: 260140 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D33190 With hat: rust Mk/Uses/cargo.mk | 2 +- Mk/bsd.gecko.mk | 2 +- lang/rust-bootstrap/Makefile | 2 +- lang/rust-bootstrap/distinfo | 6 +- lang/rust/Makefile | 9 +- lang/rust/distinfo | 114 ++++++++++----------- .../{ => no-hardlinks}/patch-src_bootstrap_lib.rs | 0 .../patch-src_bootstrap_native.rs | 0 ...ch-library_backtrace_src_backtrace_mod.rs (new) | 10 ++ .../files/patch-vendor_cc-1.0.69_src_lib.rs (new) | 38 +++++++ .../patch-vendor_openssl-sys_build_main.rs (new) | 19 ++++ lang/rust/update.sh | 31 ++---- 12 files changed, 144 insertions(+), 89 deletions(-)
<https://lists.freebsd.org/archives/freebsd-gecko/2023-April/001429.html> identifies this bug report as one of seven that need special attention. Is it possible to summarise the current situation? Thanks
The last time I compiled this was in Sep. 2022, directly on the RPI-B because qemu-user-static was not working anymore (see PR 267346). It must have been working because I have the following generated packages, among others: [0]# ll -tr /z/release/FreeBSD-ports/armv6/packages-14/All | egrep 'rust|llvm' -rw-r--r-- 1 nobody srcs 118219991 Sep 4 2022 rust-1.62.1.pkg -rw-r--r-- 1 nobody srcs 4613334 Sep 4 2022 librsvg2-rust-2.54.1_3.pkg -rw-r--r-- 1 nobody srcs 163103813 Oct 6 2022 llvm13-13.0.1_3.pkg -rw-r--r-- 1 nobody srcs 1438540 Oct 6 2022 rust-cbindgen-0.24.3_1.pkg [0]# I am waiting for qemu-user-static to start working again before continuing building for armv6. -- Martin
(In reply to Graham Perrin from comment #45) We don't support rust on armv6 anymore.