Skip to content
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.

Sign up for GitHub

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

Jump to bottom

building rust infinite loops in __memset_sse2 on Indiana University network machines (RHEL 6.4 x64) #8621

Closed
toddaaro opened this issue Aug 19, 2013 · 2 comments
Closed

building rust infinite loops in __memset_sse2 on Indiana University network machines (RHEL 6.4 x64) #8621

toddaaro opened this issue Aug 19, 2013 · 2 comments
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@toddaaro
Copy link
Contributor

This is a mysterious issue. Something about the configuration of the Indiana University network results in rustc infinite looping during make. This has been reproduced on three different machines and two user accounts. Attaching gdb to the running rustc process spots a number of threads waiting and one in __memset_sse2. So far every (10+) gdb attach has had the same memset call on top of the backtrace.

Here are a few pastes that might be useful. The first is a configure + check-stage0-std output. The second is gdb attached and used to get a pair backtraces.

pastebin.mozilla.org/2884116
pastebin.mozilla.org/2884115

The machine configurations are 64 bit Redhat Linux Enterprise Edition 6.4 (Santiago). Glibc is version 2.12, and gcc is version 4.4.6-3 Redhat.
@toddaaro
Copy link
Contributor Author

Still haven't followed up on this. I might not get to it until late next week.

@alexcrichton
Copy link
Member

Due to lack of reproducability and the pastebins being gone now, I'm going to close this. It'd be tough for us to even verify whether a fix worked or not sadly.

xFrednet pushed a commit to xFrednet/rust that referenced this issue May 21, 2022
@bors
Auto merge of rust-lang#8621 - Jarcho:eval_order_dependence_4637, r=J…
1c0a61e 
…archo

Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery

As per the [reference](https://doc.rust-lang.org/1.51.0/reference/expressions.html#evaluation-order-of-operands) evaluation order is now defined.

I'm pretty sure rust always compiled with this evaluation order anyways so there's no reason the put an msrv limit on the lint.

changelog: Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @toddaaro