Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Listing lines that can panic in your crate #50

Closed
RazrFalcon opened this issue Feb 8, 2019 · 15 comments
Closed

Listing lines that can panic in your crate #50

RazrFalcon opened this issue Feb 8, 2019 · 15 comments

Comments

@RazrFalcon
Copy link

Is it possible? Something like this:

text[5..100]; // Line N can panic
@RazrFalcon
Copy link
Author

Whoops, this crate is about unsafe, not panics.

@anderejd
Copy link
Contributor

anderejd commented Feb 8, 2019

Interesting idea though!

And, it's extra important to be panic/exception safe inside unsafe blocks, right? Finding potential panic sites inside unsafe blocks would be valuable.

@alexchandel
Copy link

alexchandel commented Jan 19, 2020

@anderejd Please reopen this as a request for counting panics (and perhaps listing their lines). Panics are very overused in libraries, and can unexpectedly crash unwary users and poison their mutexes.

@RazrFalcon
Copy link
Author

@alexchandel Afaik, cargo-geiger simply parses the source code for unsafe. It's not enough to find panics. For example, a pretty common slicing will be a problem.

@anderejd
Copy link
Contributor

anderejd commented Jan 19, 2020

@alexchandel RazorFalcon is correct, this tools is not capable if that kind of analysis, at least not without a major rewrite. Maybe you would be interested in this: https://crates.io/crates/no-panic ?

@alexchandel
Copy link

Yes, but sometimes "no-panic" isn't achievable. What's needed is an analysis of panicking routes, for minimization. It might not be feasible now, but given the nature of panicking, it fits the idea of a "geiger counter."

Slicing might show up a lot (absent a flag to ignore slicing panics), but often the compiler can prove a slice will never panic.

@tarcieri
Copy link
Collaborator

This sounds like it needs a call graph analyzer ala https://github.com/trailofbits/siderophile

@alexchandel
Copy link

Oh perhaps. I'll open it there.

@Shnatsel
Copy link

https://github.com/Technolution/rustig already addresses this

@RazrFalcon
Copy link
Author

@Shnatsel Does it actually works? Looks like it is abandoned and last time I've checked it didn't do anything.

@Shnatsel
Copy link

I haven't tried it in a while, so can't really comment.

@anderejd
Copy link
Contributor

It seems this discussion is coming to life again, let's re-open the issue to make it more visible.

@anderejd anderejd reopened this Feb 29, 2020
@pinkforest
Copy link
Collaborator

Well I went down a rabbithole today related to panic caused by the usual library-unwrap() and Err() pattern that had affected us and some others e.g. tarpaulin.

#83 (comment)

I have a "want" to track down this pattern across ecosystem in weighted manner (I already have a synced & tracked copy of it) to trace that kind of pattern across libs to create analysis from weakest points in the ecosystem related to the pattern - binaries can panic all they want.

I'll close this issue so it doesn't confuse from repo issues - if we find a security related use we could add issue in rust-secure-code/wg

Perhaps we can moderate a moonshots tracker idea issue somewhere and refer from there to here so it's neither buried under a lot of other stuff e.g. repo issues.

@8573
Copy link

8573 commented May 17, 2022

Is it possible? Something like this:

text[5..100]; // Line N can panic

Without suggesting reopening this ticket, I note that some use-cases for this may be served by the many Clippy lints returned by searching the Clippy lint index for "panic", with Indexing in particular being covered by indexing_slicing.

@pinkforest
Copy link
Collaborator

Since clippy has introduced very geiger relevant #247 and we are thinking of introducing clippy runner as part of 0.12 this may be viable as a feature to plug into

I'll convert this into discussion re: feasibility discussion

@pinkforest pinkforest reopened this May 18, 2022
@geiger-rs geiger-rs locked and limited conversation to collaborators May 18, 2022
@pinkforest pinkforest converted this issue into discussion #315 May 18, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants