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.

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

Update LLVM #16927

Merged
merged 1 commit into from
Sep 9, 2014
Merged

Update LLVM #16927

merged 1 commit into from
Sep 9, 2014

Conversation

dotdash
Copy link
Contributor

@dotdash dotdash commented Sep 1, 2014

No description provided.

@dotdash
Copy link
Contributor Author

dotdash commented Sep 3, 2014

Can somebody with access to a Mac help debugging this? I can't reproduce the problem on linux.

@vhbit
Copy link
Contributor

vhbit commented Sep 3, 2014

I can reproduce it on Mac, checked a couple of produced cores and the common pattern is:

thread #9: tid = 0x0008, 0x000000010a9164f8 librustc_llvm-4e7c5e5c.dylib`void std::__1::__tree_balance_after_insert<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*) + 328, stop reason = signal SIGSTOP
    frame #0: 0x000000010a9164f8 librustc_llvm-4e7c5e5c.dylib`void std::__1::__tree_balance_after_insert<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*) + 328
librustc_llvm-4e7c5e5c.dylib`void std::__1::__tree_balance_after_insert<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*) + 328:
-> 0x10a9164f8:  movq   (%rcx), %rdx
   0x10a9164fb:  testq  %rdx, %rdx
   0x10a9164fe:  movq   %rdx, 0x8(%rax)
   0x10a916502:  je     0x10a916508               ; void std::__1::__tree_balance_after_insert<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*) + 344

The fun thing is that crashes aren't stable, i.e. rerunning tests indefinitely will make all of them pass. Also it happens only on tests from rustdoc.

So most probably LLVM internally uses non-thread-safe tree and if rustdoc test runner uses concurrency extensively (I'm not familiar with it but considering every core has 14 threads it's very likely) - it might be just a matter of luck on how long LLVM will not fail.

@alexcrichton?

@vhbit
Copy link
Contributor

vhbit commented Sep 3, 2014

Here are a couple of full stacktraces

@alexcrichton
Copy link
Member

Yeah I was able to reproduce what @vhbit was seeing as well. It looks like LLVM is not exactly threadsafe where it says it's threadsafe (bug in LLVM, sadly).

@bors bors closed this Sep 9, 2014
@bors bors merged commit cdfa637 into rust-lang:master Sep 9, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 31, 2024
fix: Rename `func_like` to `FuncLike`

Should fix rust-lang#16926. Please check the issue for more information.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants