Asan finds memory leaks. #524
Comments
|
Is it because of the lazy_statics? Lazy static memory is never freed. |
|
In this instance, it does seem related to a lazy_static. A lazy_static won't trigger asan alone. For example asan is fine with: In iced, one of the problematic lazy statics is the result of a function that leaks a I can make a similar leak with this minimal example: Maybe it can be fixed by keeping a reference to the Box alive? |
Looks like it's saved in the mnemonics vec which is then saved in the lazy static. |
|
Right, but I suspect it's because you store a raw pointer. Having read the code a bit more, the pattern you use is like this: ^ This does upset asan. Whereas this doesn't: It seems that keeping a static reference to a leaked box to something is fine for asan, but keeping a raw pointer to a leaked box alone is not sufficient. Note also the deletion of the |
|
So it's not a memory leak just a false positive. If you want to implement the workaround, I'll accept the PR. |
I'm not sure. Could be the case that with a reference, the memory is actually freed, whereas with a raw pointer it is not... I don't know. I'm out of my depth here, so I think I need to ask on Zulip. |
|
It's a lazy static so nothing will be freed. |
|
Yeah, that's my intuition too. The lazy_static docs even say: So why does asan not puke on the example where we keep hold of a reference to the leaked box? |
|
I don't know anything about the implementation of ASAN, but your two examples above show it's a false positive. |
|
Having spoken on Zulip, it seems likely that the second example is a false negative. I'll see if I can fix this, but if it gets too difficult, I reserve the right to wimp out :) |
|
Do you mean false positive? I don't see how your examples above have memory leaks since everything is stored in a lazy static which never gets freed and is never supposed to be freed (it's |
|
I've had a look at a fix, and I don't think it's something I'm going to get right. I think you need to hold a rust reference to all static memory at the time the process exits. I was trying to hold a slice to the vector backing, but it quickly got complicated. |
|
The problem isn't related to pointer vs reference (asan doesn't know anything about pointers vs references) Manually expanding out the example that ASAN complains about: let mut outer_vec: Vec<Thingy> = Vec::new();
let inner_vec: Vec<u8> = Vec::new(); // inner_vec is on the stack, its data is allocated on the heap
let tmp_boxed_vec: Box<Vec<u8>> = Box::new(inner_vec); // Now we box the vec itself (a data pointer, a length and a capacity), so there are two allocations, the box, and then the data inside the vec.
let tmp_vec_ref: &'static Vec<u8> = Box::leak(tmp_boxed_vec);
let leaked: *const u8 = tmp_vec_ref.as_ptr(); // We no longer have a pointer to the Vec which was boxed, only the vec's data
outer_vec.push(Thingy(leaked));
outer_vecInstead, you can use |
|
Planning to open a PR to fix |
|
Thanks!
…On Sat, 24 Feb 2024, 17:55 wtfsck, ***@***.***> wrote:
Closed #524 <#524> as completed
via #528 <#528>.
—
Reply to this email directly, view it on GitHub
<#524 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAETWG3CR3QGZMENIYR4PTLYVISPTAVCNFSM6AAAAABDTCK4E6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRHEYTCMRXG42DGMI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I noticed this when my project's CI failed after using iced_x86 for the first time.
If you run the Rust test suite with Asan enabled, there are a lot of leaks reported. e.g.:
They are likely to be real leaks, as the unstable book says:
The text was updated successfully, but these errors were encountered: