-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mrustc 0.8.0 fails to build rust 1.19.0 on i686 #108
Comments
|
#109 may be related, but just fixing it didn't fix the crash. |
We've reduced the crash to the following smaller test case:
I suspect that the child processes' input deserializer is broken. Base64 encoded, the
sha256 sum of
|
Same with current git master of mrustc, commit 7b6fa5c. |
Hmm... works for me, using |
Could you post the generated C code (the output of mrustc) of the working libserde_derive? The failing C code is attached to the post at http://lists.gnu.org/archive/html/guix-devel/2019-02/msg00055.html (Currently using gcc is 5.5.0 on Guix) |
Looking at the backtrace above, I can see two things.
Second, that line number doesn't match the line numbers in my build of current master (7d728e4) Can you try again with that revision, potentially running with valgrind? |
Oops, with mrustc master, the failure is different! Then, it fails on
with SIGABORT.
|
see #78, iikely seeing the same failure |
Could be. How can I debug it further? |
It looks like a panic from a bad enum tag, probably caused by memory corruption or bad structure alignment/sizes. Probably need to do some legwork to trace where the bad value is coming from. |
I can do the legwork, but where do I start? Can I use valgrind memcheck on mrustc? |
on the output, sure. |
Without valgrind, with current mrustc master (commit 3f44cec)'s compiled rust 1.19.0, I get SIGFPE on the const evaluator now :) With valgrind, I get SIGABRT:
Hmm, no debug symbols? I thought I saw a "-g" in the mrustc invocation? Hrrrm.... |
mrustc master-compiled rustc 1.19.0 as of mrustc commit 3f44cec doesn't work on x86_64 either, and fails with pretty similar error. In a way that's good because I have much better debugging tools for x86_64.
|
Works for me on x86_64 (gcc 6.3.0-18+deb9u1), might be some UB being triggered |
FWIW We've been through some major gcc upgrades by now and the i686 failure with mrustc 0.8.0 is always the same. To reproduce, invoke We are now at gcc 8.3.0--still the same failure happens. Newest backtrace with the small reproducer is:
Hexdump (od -tx1) of the
Valgrind memcheck of the small reproducer is:
|
Sorry, I've not put any time into tracing the root cause of this bug (instead been focussing on the 1.29 branch, which includes a lot of general compiler fixes). Can you confirm that the above failure still happens on 3f44cec (current |
The above failure does not happen on 3f44cec, but the compiler rustc 1.19.0 compiled via that mrustc does die with a signal when it is used. The following logs are all from a 3f44cec run. Backtrace of first run_rustc command from a manual attempt ("x86_64-unknown-linux-gnu" is just because I didn't edit run_rustc's Makefile, it's actually i686):
That location contains:
Valgrind reports no errors before the abort. Using the rustc 1.19.0 compiler above to compile a toy program results in:
Then we tried our package recipe that worked before for 0.8.0 x86_64, tried it on i686-linux with the mrustc commit 3f44cec (the rustc calls for libcore have a lot more options specified), and we get: mrustc proceeds until it tries to use the newly-built rustc compiler to build libcore, then we get
(eax = 1, esp = 0xf4e46e50) gcc 5.5.0 (native i686, not a cross compiler). And on x86_64 with that mrustc-compiled rust we get SIGABRT:
Valgrind reports a massive number of jumps depending on uninitialized values before the abort (they look spurious to me). And sometimes this happens:
However, compiling This is on a stable release of the Guix distribution, 1.0.0, with standard compiler and everything. If you would like, we can give you an account on a Guix machine. We take reproducible builds very seriously so it's quite easy to have exactly the dependencies one wants available and none other. It's also possible (and supported) to install Guix on any other Linux distribution (https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.i686-linux.tar.xz - extract to /) and use it as a building and testing environment in parallel to using the original distribution (it takes a lot of disk space in operation, like 20 GB). |
That's more that I'd expect. There appears to be some form of floating-point bug somewhere, but due to the design of the x87 FPU it's very hard to tell where. |
Rust 1.19.0 fails to build via mrustc 0.8.0 on i686:
The text was updated successfully, but these errors were encountered: