Valgrind reports allocated mem at close about x11-rs HOT 5 OPEN

It's probably caused by ::std::mem::forget(lib); at link.rs:60.

from x11-rs.

If you still have that code, can you post the valgrind output? That line with forget(lib) shouldn't be causing any problems to my knowledge. The swap just before it ensures that lib is null, and forget is called just to prevent the destructor from being called. It's not a nice way to accomplish what I wanted, but I wrote that code when I was new to Rust <.<

Sorry for the delayed response. I haven't had time for x11-dl since I started going back to college, and I don't have anyone else to maintain it for me.

from x11-rs.

Hi, no problem! The output is in the <details> tag, unless you mean something else?

from x11-rs.

Whoops! I guess I missed that.

Digging through this, I'm noticing how ugly my old code is and remembering that I was rushing to get it working at the time, but in the process, I remembered something that I was fighting with when I wrote the code.

There was an issue somebody opened a long time ago in which Xlib::open() (for each library struct) was crasing on some systems because it was using an absurd amount of stack memory, so I changed the function in a way that guarantees that only one copy of the struct could possibly be allocated on the stack. The init function initializes the members by taking a pointer to the huge struct instead of returning an instance on success, as you would normally do in Rust.

While I was making this change, something strange happened. I wrote the destructor for DynamicLibrary to check if the handle was null before calling dlclose, which seemed like a simple solution to a simple problem at the time. The only member in DynamicLibrary is the handle, so an instance initialized with mem::zeroed() shouldn't cause any problems. But for some reason it did. The very simple destructor for the very simple struct was crashing, and to this day, I still have no idea why.

I used mem::swap() and mem::forget() to get around this weird problem. There are two instances of DynamicLibrary: one within the library struct and a temporary one. The one inside the struct gets a valid handle which should be cleaned up with dlclose when it is dropped, while the temporary one (which should be null after the swap) goes away with mem::forget() to prevent the somehow crashing destructor from being called.

Judging by the valgrind output, it looks like dlclose isn't being called. In my code in another project, the only Xlib struct instantiated is inside a lazy_static, so you would expect it to never be destroyed, but if Xlib is dropped, then I don't see any reason that dlclose would not be called. This is unsatisfying to say, but I have no idea why the code isn't working (or why the destructor used to crash in the old code before I push the current code). Maybe there's something obvious going on that I'm just missing for some reason.

from x11-rs.

I'm not sure it's such a major problem to be honest, maybe just leave the issue open?

from x11-rs.