Bug 259799 - devel/rust-cbindgen: armv6: build using "make" fails, using "cargo build --release -j 1" works
Summary: devel/rust-cbindgen: armv6: build using "make" fails, using "cargo build --re...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Rust Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-12 16:55 UTC by Martin Birgmeier
Modified: 2021-12-05 12:36 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (gecko)


Attachments
log file of building rust-cbindgen (238.73 KB, text/plain)
2021-11-12 17:33 UTC, Martin Birgmeier
no flags Details
armv6 installed ports (8.08 KB, text/plain)
2021-11-12 18:50 UTC, Martin Birgmeier
no flags Details
log file of running portmaster to build rust-cbindgen (162.44 KB, text/plain)
2021-11-12 19:07 UTC, Martin Birgmeier
no flags Details
succeeding build when going into the port build dir and manually running "cargo build --release" (1.11 KB, text/plain)
2021-11-12 19:07 UTC, Martin Birgmeier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2021-11-12 16:55:51 UTC
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
Comment 1 Martin Birgmeier 2021-11-12 17:33:10 UTC
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
Comment 2 Jan Beich freebsd_committer 2021-11-12 18:32:52 UTC

*** This bug has been marked as a duplicate of bug 257419 ***
Comment 3 Martin Birgmeier 2021-11-12 18:50:40 UTC
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.
Comment 4 Mark Millard 2021-11-12 19:01:53 UTC
(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
Comment 5 Martin Birgmeier 2021-11-12 19:04:48 UTC
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
Comment 6 Martin Birgmeier 2021-11-12 19:07:14 UTC
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
Comment 7 Martin Birgmeier 2021-11-12 19:07:59 UTC
Created attachment 229453 [details]
succeeding build when going into the port build dir and manually running "cargo build --release"
Comment 8 Martin Birgmeier 2021-11-12 19:09:17 UTC
Note regarding the cargo build: I actually ran "cargo build --release -j 1" in order not to trip on the indefinite wait.
Comment 9 Mark Millard 2021-11-12 19:11:07 UTC
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.)
Comment 10 Mark Millard 2021-11-12 19:17:37 UTC
(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.
Comment 11 Martin Birgmeier 2021-11-12 19:21:52 UTC
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
Comment 12 Jan Beich freebsd_committer 2021-11-12 19:24:01 UTC
(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.
Comment 13 Martin Birgmeier 2021-11-12 19:27:23 UTC
(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
Comment 14 Martin Birgmeier 2021-11-12 19:28:55 UTC
(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
Comment 15 Martin Birgmeier 2021-11-12 19:39:45 UTC
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
Comment 16 Mark Millard 2021-11-12 19:49:18 UTC
(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.
Comment 17 Mark Millard 2021-11-12 19:52:53 UTC
(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.
Comment 18 Mark Millard 2021-11-12 20:02:25 UTC
(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.
Comment 19 Jan Beich freebsd_committer 2021-11-12 20:04:26 UTC
(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//'
Comment 20 Mark Millard 2021-11-12 20:31:00 UTC
(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.
Comment 21 Mark Millard 2021-11-12 21:36:51 UTC
(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.)
Comment 22 Martin Birgmeier 2021-11-13 08:36:40 UTC
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
Comment 23 Martin Birgmeier 2021-11-13 08:46:50 UTC
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.
Comment 24 Mark Millard 2021-11-13 09:00:36 UTC
(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.
Comment 25 Mark Millard 2021-11-13 09:27:11 UTC
(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
Comment 26 Martin Birgmeier 2021-11-13 09:38:34 UTC
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
Comment 27 Mark Millard 2021-11-13 10:08:43 UTC
(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.)
Comment 28 Mark Millard 2021-11-13 10:18:07 UTC
(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).
Comment 29 Mark Millard 2021-11-13 11:35:15 UTC
(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 . . .
Comment 30 Mark Millard 2021-11-13 11:49:45 UTC
(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
Comment 31 Mark Millard 2021-11-13 22:49:42 UTC
(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.
Comment 32 Mark Millard 2021-11-13 23:03:06 UTC
(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.
Comment 33 Martin Birgmeier 2021-11-14 08:00:16 UTC
(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
Comment 34 Mark Millard 2021-11-14 10:16:20 UTC
(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.
Comment 35 Mark Millard 2021-11-16 19:24:39 UTC
(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.)
Comment 36 Mark Millard 2021-11-26 19:50:17 UTC
(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.
Comment 37 Mark Millard 2021-11-26 21:36:31 UTC
(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.
Comment 38 Mark Millard 2021-11-27 02:30:55 UTC
(In reply to Mark Millard from comment #37)

"debug symbols" was the wrong phrase: "debug information"
would have been better.
Comment 39 Mark Millard 2021-11-27 03:37:56 UTC
(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?)
Comment 40 Tobias Kortkamp freebsd_committer 2021-11-27 08:12:27 UTC
(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/).
Comment 41 Mark Millard 2021-11-27 14:31:37 UTC
(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 ()
Comment 42 Mark Millard 2021-11-27 14:46:43 UTC
(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.
Comment 43 Mikael Urankar freebsd_committer 2021-11-28 17:58:06 UTC
(In reply to Tobias Kortkamp from comment #40)
that works, thanks.
Comment 44 commit-hook freebsd_committer 2021-12-05 12:36:27 UTC
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(-)