-
Notifications
You must be signed in to change notification settings - Fork 54
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
Memory leak with "use" statement #252
Comments
What platform are you using? |
Oh sorry, I forgot to mention it. I'm on Linux, on NixOS (on the nixos-unstable branch, updated a few days ago). |
I strongly suspect that it's not an issue in softbuffer, could you try to do the same with our Linux dependencies: # Cargo.toml
as-raw-xcb-connection = "1.0.0"
bytemuck = "1.12.3"
drm = { version = "0.14.1", default-features = false }
fastrand = "2.0.0"
memmap2 = "0.9.0"
rustix = { version = "0.38.19", features = [
"fs",
"mm",
"shm",
"std",
], default-features = false }
tiny-xlib = "0.2.1"
wayland-backend = { version = "0.3.0", features = [
"client_system",
] }
wayland-client = "0.31.0"
wayland-sys = "0.31.0"
x11rb = { version = "0.13.0", features = [
"allow-unsafe-code",
"shm",
] } And test a |
From the full output, everything seems to be rooted in dlopen. I'd investigate what's calling dlopen (using a debugger), and also why it's not also calling dlclose. |
Just |
strace may not be sufficient to determine what's doing the loading, which (considering the no-op example) is I think the greater mystery here. |
idk, strace was more than enough. It's done by tiny-xlib here https://github.com/notgull/tiny-xlib/blob/main/src/lib.rs#L150 due to use of Tbf, this is not a big of a deal, I'd say, and the |
I tried what you said, and I don't have any memory leak. I just have more heap usage.
However I discovered something: with nix we can specify Linux build dependencies per project, and like a fool I didn't used the same Linux dependencies in my project and in my example. In my example I used "wayland" and "xorg.libX11", but if I replace the last one with "libxkbcommon" the results are differents. use softbuffer as _;
fn main() {} [package]
name = "use-ml"
version = "0.1.0"
edition = "2021"
[dependencies]
softbuffer = "0.4.6" Short output:
Long output:
But again with your example I don't have memory leak. Note that libxkbcommon wasn't enough, I had to add libX11, so I think it's related to libxkbcommon. Morover when I put libX11 AND libxkbcommon in the Linux dependencies, and I have the output I had without libxkbcommon (so my second example, in my first message) I think there is something between the rust dependency "tiny-xlib" and the Linux dependency "libxkbcommon", however it doesn't happen when I import "tiny-xlib" without "softbuffer" |
@polnio I've already debugged your issue, so don't waste your time. See #252 (comment) |
Yes, but it seems that it's not just about tiny-xlib, because like I said it doesn't happen when I import this crate instead of softbuffer |
@polnio it doesn't matter, the point is that it's done by Other crates could do so as well, in the softbuffer case, you can clearly see in strace what is being loaded, you can do the same with other crates. It doesn't happen when you import this crate, because you don't enable |
The issue
When I import anything from this crate, valgrind detect a memory leak, even if I'm not using what I'm importing, and even in release mode.
Node that when I encountered it the first time, it was on a bigger project, and valgrind didn't print the same output even with the same code: instead of 9,956 bytes still reachable, I had 137 bytes possibly lost, and it was related to tiny-xlib (but I don't have the issue when I import tiny-xlib in my code). Maybe it's due to other dependencies, even if they aren't included in my code... It's still quite strange.
Additional informations
softbuffer version : 0.4.6
Rust version : 1.82.0
Valgrind version : 3.23.0
Example 1: no memory leak
Valgrind output:
Example 2: memory leak
Valgrind output:
Valgrind full output:
The text was updated successfully, but these errors were encountered: