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:
- A safe constructor which forces
remove_on_drop to true
- 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?
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
Timeris dropped before SDL fires the callback, and theremove_on_dropflag 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 theTimerwhich was just dropped.A possible solution is splitting the constructor into two constructors:
remove_on_dropto trueremove_on_dropflags themselvesremove_on_drop: falsewill only work in the case that the closure lives longer than theTimer<'a>.Perhaps there is some other way we could express this w/ lifetime bounds, though?