Upgrade Rust to 1.67.1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
rustc |
Fix Released
|
Medium
|
|||
rustc (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Upgrade Rust to 1.67.1
Zixing Liu (liushuyu-011) wrote : | #1 |
Zixing Liu (liushuyu-011) wrote : | #2 |
Updated and fixed packages are available in https:/
Changed in rustc (Ubuntu): | |
status: | New → In Progress |
Zixing Liu (liushuyu-011) wrote : | #3 |
Notable packaging changes since Rust 1.66.1:
- Disable SSE2-related stuff on i386 (since our baseline is not i686 w/ SSE2)
You can find other changes documented in the changelog of the source package.
Simon Chopin (schopin) wrote : | #4 |
Hi Zixing,
I'm assuming you're using https:/
Could you please use DEP-3 headers on any new patch? https:/
This makes it easier to reason about patches, share them with other distros, etc...
Zixing Liu (liushuyu-011) wrote : | #5 |
Hi Simon,
Yes, the changes are done on https:/
I have added the DEP-3 headers to the new patch introduced for fixing the i386 build (the only new patch).
Simon Chopin (schopin) wrote : | #6 |
Uploaded, thanks!
Zixing Liu (liushuyu-011) wrote : | #7 |
I have discovered a critical issue with the upload. Can we retract version 1.67.1 from the archive for now?
The binary in the current archive can not find the standard library due to an upstream change: https:/
The change in question was a fix to the Windows version of the Rust compiler, but it seems like it broke our situation where the `multiarch` layout is used in /usr/lib.
This change was not tested in the test suite, so it was not caught during the build. When I installed the binary from the archive, I detected this issue.
Sorry for not catching this early. This will also block the Cargo upload for now due to buildability.
Zixing Liu (liushuyu-011) wrote : | #8 |
To conclude, how this happened but flew under the radar (both upstream and us):
- The author of that upstream change did not consider the possibility of breaking Linux distros like Debian (they stated in the PR that "this finds the sysroot using Rust driver DLLs."
- "Modern" Linux distros did not encounter this issue because they use non-multiarch layout.
- Some other Linux distros discovered the issue but stayed silent and worked around it using their own mechanisms.
- I did not discover this issue because the new Cargo 0.68 was built using Rust 1.66, and the test suite for Rust 1.67 did not include tests for testing directory look-up.
In the future, I will add a basic smoke test for Rust to prevent this kind of issue and catch the problem early.
Zixing Liu (liushuyu-011) wrote (last edit ): | #9 |
I have added a patch to address this issue.
The patch was also forwarded to Rust upstream: https:/
The fixed batch was uploaded to the PPA as version 1.67.1+
The series of changes to fix the issue were added to https:/
Zixing Liu (liushuyu-011) wrote : | #10 |
Also, test failures in i386 and ppc64el are due to a recent GDB upload in LL.
The Rust test suite has tests that launch GDB to inspect debug information.
GDB threw some internal errors in those tests:
/build/
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5668dc91 ???
0x56a9bd24 ???
0x56a9bfae ???
0x56bd1378 ???
0x567f0b6f ???
0x567618f1 ???
0x56761e24 ???
0x56761f4b ???
0x569e49f4 ???
0x569e593c ???
0x569e9c9d ???
0x569ea9be ???
0x5684d5a6 ???
0x566cddd5 ???
0x5685002c ???
0x5686222a ???
0x5682fb2e ???
0x56880fa9 ???
0x56bd1575 ???
0x56bd183b ???
0x56bd2406 ???
0x56a53c02 ???
0x56a53c84 ???
0x56a541cb ???
0x567c1e58 ???
0x56a5640e ???
0x566d42c6 ???
0x566c4d8d ???
0x568ac8aa ???
0x568ac96d ???
0x568aeb94 ???
0x568af94f ???
0x565e64d9 ???
0xf6e2a8f8 ???
0xf6e2a9bb __libc_start_main
0x565edb1a ???
0xffffffff ???
-------
This is a bug, please report it. For instructions, see:
<https:/
Łukasz Zemczak (sil2100) wrote : | #11 |
Removing packages from lunar-proposed:
rustc 1.67.1+
Comment: Requested by uploader, contains critical issue: https:/
Remove [y|N]? y
1 package successfully removed.
Package should now be removed from lunar-proposed.
In Sourceware.org Bugzilla #30158, Matthias Klose (doko) wrote : | #15 |
the rustc testsuite fails with 13.1 on i686-linux-gnu and powerpc64le-
https:/
claims:
/build/
A problem internal to GDB has been detected,
further debugging may prove unreliable.
https:/
same internal error
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #16 |
Created attachment 14714
test case with readme
Attaching code that reproduces the issue. See README file.
Original source: https:/
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #17 |
With attached testcase I am able to reproduce the issue using gdb 13.1, but it works using 13.0.91.20230210.
It might be related to the patch that fixed PR/30116.
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #18 |
Ugh. I'll investigate.
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #19 |
I confirm that reverting patch for PR/30116 makes the rust testsuite work again (for me).
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #20 |
The crash is in inside_
commit 9370fd51ebfca8a
gdb: detect main function even when there's no matching msymbol
First, gdb doesn't find the minsym, probably because the msyms
contain:
[99] t 0x90c0 _ZN17rustc_
... but we're looking for:
(top-gdb) p name
$13 = 0x292e0c0 "rustc_
The _Z overloading strikes again.
Anyway somehow we find a full symbol for this, but it doesn't
have a block, so the assert fails.
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #21 |
rustc decides to emit both:
<2><2f5b>: Abbrev Number: 10 (DW_TAG_subprogram)
...
<2f6e> DW_AT_name : (indirect string, offset: 0x23a): main
and
<2><2f95>: Abbrev Number: 2 (DW_TAG_namespace)
<2f96> DW_AT_name : (indirect string, offset: 0x23a): main
in the same scope.
Then the lookup finds the wrong one, because gdb's symbol tables
are bad and still follow C namespace rules.
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #22 |
We can avoid the crash pretty easily but stopping the 'bt'
before _start is harder.
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #23 |
Another thought here is it would probably be better on the whole
to use the main symbol's linkage name; but that too seems like
a larger change.
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #24 |
https:/
I'll apply to the gdb 13 branch as well when it goes in.
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #25 |
(In reply to Tom Tromey from comment #9)
> https:/
Thanks! That worked with the test case.
Zixing Liu (liushuyu-011) wrote (last edit ): | #12 |
GDB issues fixed in https:/
`rustc` builds were retried and confirmed to be passed.
Changed in rustc (Ubuntu): | |
status: | In Progress → Fix Committed |
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #26 |
Hello Tom,
The testcase at https:/
Fabian reports:
I updated the reproducer repo[0], broken and good output look like this:
----8<---- broken
Breakpoint 1 at 0x81dd: file src/main.rs, line 88.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
Breakpoint 1, rustc_gdb_
88 zzz(); // #break
$1 = &rustc_
$2 = &rustc_
$3 = &rustc_
warning: (Error: pc 0x5555555a3000 in address map, but not in symtab.)
}
$4 = alloc::
warning: (Error: pc 0x5555555a3000 in address map, but not in symtab.)
}
$5 = &(i32, i32, [i32]) [(0, 1, 0), (2, 3, 0)]
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x5555555a3020, vtable: 0x5555555a3030w
warning: (Error: pc 0x5555555a3030 in address map, but not in symtab.)
}
---->8----
----8<---- good (gdb 12.1-4 from bookworm)
Breakpoint 1 at 0x81dd: file src/main.rs, line 88.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
Breakpoint 1, rustc_gdb_
88 zzz(); // #break
$1 = &rustc_
$2 = &rustc_
$3 = &rustc_
$4 = alloc::
$5 = &(i32, i32, [i32]) {data_ptr: 0x555555593038, length: 2}
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x5555555a3020, vtable: 0x5555555a3030}
---->8----
Since this no longer (fatally) affects the build of rustc, I opted for a
lower severity this time around. It looks like an issue with symbol
mapping/lookup again. Feel free to adjust if you consider this blocking.
0: https:/
I am attaching last git reproducer to the bug
In Sourceware.org Bugzilla #30158, Hector Oron (zumbi) wrote : | #27 |
Created attachment 14721
test case with readme (v2) - one last issue after proposed patch
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #28 |
(In reply to HectorOron from comment #11)
> Since this no longer (fatally) affects the build of rustc, I opted for a
> lower severity this time around. It looks like an issue with symbol
> mapping/lookup again. Feel free to adjust if you consider this blocking.
Would you mind submitting a separate bug for this?
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #29 |
Marking for 13.2
Zixing Liu (liushuyu-011) wrote (last edit ): | #13 |
Another refreshed build of Rust 1.67.1 has been uploaded to LL.
This build contains an updated patch that was iterated in the Rust upstream.
EVR for this build is 1.67.1+
You can find the source at https:/
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #30 |
*** Bug 30224 has been marked as a duplicate of this bug. ***
In Sourceware.org Bugzilla #30158, Cvs-commit (cvs-commit) wrote : | #31 |
The master branch has been updated by Tom Tromey <email address hidden>:
https:/
commit 5f056fcb3dce947
Author: Tom Tromey <email address hidden>
Date: Fri Feb 24 10:40:16 2023 -0700
Fix crash in inside_main_func
gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name
$13 = 0x292e0c0 "rustc_
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
In Sourceware.org Bugzilla #30158, Cvs-commit (cvs-commit) wrote : | #32 |
The gdb-13-branch branch has been updated by Tom Tromey <email address hidden>:
https:/
commit 562403d4f5483e0
Author: Tom Tromey <email address hidden>
Date: Fri Feb 24 10:40:16 2023 -0700
Fix crash in inside_main_func
gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name
$13 = 0x292e0c0 "rustc_
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
Bug: https:/
(cherry picked from commit 5f056fcb3dce947
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #33 |
Fixed.
Launchpad Janitor (janitor) wrote : | #14 |
This bug was fixed in the package rustc - 1.67.1+
---------------
rustc (1.67.1+
* Fix an issue where rustc can not find the standard library
- d/p/ubuntu-
logic so that rustc will find the correct library paths to
search in.
rustc (1.67.1+
* New upstream release 1.67.1 (LP: #2007642)
- d/p/d-bootstrap
- d/p/ubuntu-
on i386 builds
- d/copyright: Update copyright information for new dependencies
and also remove copyright data for deleted dependencies
- d/patches: Refresh patches
- d/control: Update vendored deps field
- d/control: Refresh vendored dependencies list
- d/source/
rustc (1.66.1+
* New upstream release 1.66.1 (LP: #2005122)
- d/control: Switch to LLVM 15 for better optimizations
- d/rules: Add workarounds for the new bootstrap tests
- d/patches: Refresh patches to adapt to the new upstream changes
- d/p/ubuntu-
Dropped, no longer needed
- d/copyright: refresh vendored crate license info
- d/libstd-
* d/rules: Enable LLVM profiler support (LP: #2002694)
-- Zixing Liu <email address hidden> Wed, 22 Feb 2023 21:38:58 -0700
Changed in rustc (Ubuntu): | |
status: | Fix Committed → Fix Released |
In Sourceware.org Bugzilla #30158, Tromey-b (tromey-b) wrote : | #34 |
*** Bug 29298 has been marked as a duplicate of this bug. ***
Changed in rustc: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
Preliminary packages are available in https:/ /launchpad. net/~liushuyu- 011/+archive/ ubuntu/ rust-updates- 1.67/+packages