-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Crash during the release of a complex structure (Rust-0.8, linux) #9690
Comments
The most likely problem here is a stack overflow (since we don't currently have segmented stacks), and although you don't have a very deep callstack, since the struct is so big maybe the call frames are huge. Try running with RUST_MIN_STACK=20000000 and seeing if it helps. If so then you can increase the amount of stack used programmatically. I'm not sure why gdb thinks the top frames are called ?? though - not sure if that could be a symptom of stack overflow or not. |
Running by "RUST_MIN_STACK=20000000 build/claymore" doesn't make any difference. GDB shows the same stack trace as well... |
We now have detection of stack overflow (in the form of printing a message and aborting the process), does the message get printed for you now? |
I will test it on master and report back. |
Sorry, it took me a while to adopt my project to the new Rust changes... It still crashes with SEGFAULT. I updated the gist log: https://gist.github.com/kvark/6792497 |
Hm, that's unfortunate. That may be pointing to a codegen-style bug, but this is almost impossible to diagnose sadly unless the test case is able to get narrowed down. I believe there are a few known bugs still related to areas like this, but I don't know if the existing ones affect codegen or not. Regardless, I'll keep my eyes open for bugs which may be affecting this one! |
I've stripped the project of most of the resources, and attached to the gist as "test-rust-unmap-crash.tgz". It requires a bunch of libs to run, though I hope you can just use the compiled ones in the archive. It also requires GLFW-3 to be installed on the machine. I imagine all you'd have to do after taking care of GLFW is:
Please let me know if you have any questions or issues in reproducing the case. |
Visiting for triage. @kvark The gist is no longer available, nor is the |
@flaper87 I haven't touched the project for quite a while, so any attempt to reproduce the issue is going to take a lot of effort. Perhaps, we can close it now, and then I'll reopen it once I get it again? |
@kvark I'm not very happy to close crash bugs but in this case it sounds good to me. THe gists with logs are gone and there's not actual way to test this (nor enough insight in the previous comments). By all means, feel free to re-open (or ping any of us to do so) this issue as soon as you can get back to it. Thanks a lot! |
add `from_raw_with_void_ptr` lint This PR `fixes rust-lang#9679` - \[x] Followed [lint naming conventions][lint_naming] - \[x] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[x] Executed `cargo dev update_lints` - \[x] Added lint documentation - \[x] Run `cargo dev fmt` --- changelog: [`from_raw_with_void_ptr`]: added new lint
After porting from Rust-0.6 to 0.8 my app started crashing on start. The stack log as well as the valgrind log are posted in https://gist.github.com/kvark/6792497
I've been told that the stack tells us it's the destructor that fails. The destructing structure is big due to being auto-generated: https://code.google.com/p/claymore-game/source/browse/util/codata/scene/chared/main.rs
There is no custom destructor anywhere within this struct, all types are declared here: https://code.google.com/p/claymore-game/source/browse/util/codata/scene/common.rs
I wasn't able to create a good test case yet - just creating and releasing the structure doesn't cut it.
My system is: x86_64 GNU/Linux 3.9.8-1-ARCH #1 SMP PREEMPT
The text was updated successfully, but these errors were encountered: