checkers does not handle lazy_static well

[kstrafe]

use checkers;
use lazy_static::lazy_static;

#[global_allocator]
static ALLOCATOR: checkers::Allocator = checkers::Allocator::system();

lazy_static! {
    pub static ref EX: Box<u32> = Box::new(123);
}

#[checkers::test]
fn checkcheck() {
    let _ = &*EX;
}

Yields

Dangling region (0x7f3940010c40-0x7f3940010c44 (size: 4, align: 4))

[udoprog]

Interesting. Thanks for the report! I'm not sure how to solve it, but at least I've proposed to expose checkers::with_muted in #6. It's not perfect since this is obviously not something you'd want to keep in production code, but at least then you can mute sections while you're tracking down memory issues.

[udoprog]

From #6

I guess one way to do it is to "initialize" the program, clear the global allocator (or mark allocated regions as DONT_CARE or something along those lines), and then run the actual test...

Maybe #[checkers::test] can run the test twice, the first time is used to set up statics and ignore them, and the second time uses the already set-up statics. If the second iteration replaced the statics, then Drop will be invoked, so all is well.

@BourgondAries It's an interesting suggestion! Would this be something you'd want to try out? I'm not sure how efficient it will be, but if it helps for your case I'd be happy to incorporate a nob that allows it to work like this.

[kstrafe]

@udoprog definitely!

That reminds me of something else, I only do a sed-all s/#[test]/#[checkers::test]/g on a project and then back. It would be even more useful if #[test] could be turned into a checkers test dynamically via some flag, instead of actually changing the source code.

But yes, just running the test twice and ignoring all regions from the first run would be somewhat better - at least for lazy_static, but it won't solve the issue completely. If the second test run overwrites the static with a new pointer we'll still be left dangling at the end of the second test.

Another suggestion here is to check if an ignored ptr from test run 1 is deallocated, and this happens during the second run, and an allocation is "nearby" with the same size and alignment, we might be able to infer that a static has been overwritten.

This might work for most cases, but it won't be able to catch dyn-based allocations, as the size may differ.

[kstrafe]

To add to the above: We might run the test N times to check if any dangling pointers are deallocated on the next run (for instance when a static Option<Box<_>> gets overwritten). If we can find a predictable, stable pattern then we should be able to deduce that those are statics and that there are no leaks if those are the only ones.