Skip to content

Potential safety violation in Timers? #264

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

Closed
drbawb opened this issue Jan 6, 2015 · 1 comment
Closed

Potential safety violation in Timers? #264

drbawb opened this issue Jan 6, 2015 · 1 comment

Comments

@drbawb
Copy link
Contributor

drbawb commented Jan 6, 2015

In writing PR #263 I believe I uncovered a soundness issue in the lifetime bounds on sdl2::timer::Timer. I've already written this up on the PR but I figured I would copy it to the issue tracker as well.


If the Timer is dropped before SDL fires the callback, and the remove_on_drop flag is not set:
then the C code is calling back into a stack-frame which just got freed.

Putting the closure in a Box<Fn() -> uint> does not help here. The boxed closure would just be stored inside the Timer which was just dropped.

A possible solution is splitting the constructor into two constructors:

  1. A safe constructor which forces remove_on_drop to true
  2. An unsafe constructor which allows the caller to set the remove_on_drop flags themselves

remove_on_drop: false will only work in the case that the closure lives longer than the Timer<'a>.
Perhaps there is some other way we could express this w/ lifetime bounds, though?

@drbawb
Copy link
Contributor Author

drbawb commented Jan 7, 2015

Closed by #265

I have some ideas for a safer API using RAII guards; but they can be implemented quite nicely on top of that PR.

@drbawb drbawb closed this as completed Jan 7, 2015
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

1 participant