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

book: claim about segfaults happening only in unsafe blocks is not true #30819

Closed
ivan opened this issue Jan 11, 2016 · 4 comments
Closed

book: claim about segfaults happening only in unsafe blocks is not true #30819

ivan opened this issue Jan 11, 2016 · 4 comments

Comments

@ivan
Copy link
Contributor

ivan commented Jan 11, 2016

If a Rust program segfaults, you can be sure it’s somewhere in the sections marked unsafe.

https://doc.rust-lang.org/nightly/book/unsafe.html

But as far as I understand it, an unsafe block can instead break an invariant that causes a segfault further down the line in safe code.

Also, stack overflows can cause a segfault.

@huonw
Copy link
Member

huonw commented Jan 11, 2016

You are correct in your understanding: the text could be tweaked to "you can be sure its cause is somewhere in the sections marked unsafe".

Also, stack overflows can cause a segfault.

NB. this is an implementation bug in rustc (#16012), i.e. this doesn't happen in a "perfect" Rust compiler (the book is designed to document the language not the details of rustc).

@mahkoh
Copy link
Contributor

mahkoh commented Jan 11, 2016

This is not quite true: http://is.gd/B4wO9H

@durka
Copy link
Contributor

durka commented Jan 11, 2016

The nomicon and Ralf disagree.

steveklabnik added a commit to steveklabnik/rust that referenced this issue Jan 11, 2016
@huonw
Copy link
Member

huonw commented Jan 11, 2016

@durka it depends what is meant by "cause"; a segfault will only occur if the program executes an unsafe block at some point, and does some unsafe operation with incorrect arguments, the point the nomicon and Ralf make is that the incorrectness in these arguments may flow from some safe piece of code. In any case, Steve's rewording is better than my proposal.

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

No branches or pull requests

5 participants