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

Crash during the release of a complex structure (Rust-0.8, linux) #9690

Closed
kvark opened this issue Oct 2, 2013 · 10 comments
Closed

Crash during the release of a complex structure (Rust-0.8, linux) #9690

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

Comments

@kvark
Copy link
Contributor

kvark commented Oct 2, 2013

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

@brson
Copy link
Contributor

brson commented Oct 6, 2013

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.

@kvark
Copy link
Contributor Author

kvark commented Oct 6, 2013

Running by "RUST_MIN_STACK=20000000 build/claymore" doesn't make any difference. GDB shows the same stack trace as well...

@alexcrichton
Copy link
Member

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?

@kvark
Copy link
Contributor Author

kvark commented Oct 29, 2013

I will test it on master and report back.

@kvark
Copy link
Contributor Author

kvark commented Nov 3, 2013

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

@alexcrichton
Copy link
Member

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!

@kvark
Copy link
Contributor Author

kvark commented Nov 7, 2013

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:

tar -xf test-rust-unmap-crash.tgz
cd test-game
make
build/claymore

Please let me know if you have any questions or issues in reproducing the case.

@flaper87
Copy link
Contributor

Visiting for triage.

@kvark The gist is no longer available, nor is the test-rust-unmap-crash.tgz Any chance you could upload it again? or perhaps create a new shorter / simpler test case?

@kvark
Copy link
Contributor Author

kvark commented Apr 15, 2014

@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?

@flaper87
Copy link
Contributor

@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!

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 21, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

No branches or pull requests

4 participants