Fix segfaults inside g_free on windows #14
Conversation
calling `libc::free` actually doesn't always work, because there are multiple heaps, and we're trying to free it from the wrong one. Instead, we find the g_free export from libglib-2.0, and invoke that. Added the `libloading` crate to help with this, and also rewrote the `delaylink_hook` to use the functions there, rather than directly calling the windows API.
|
I don't know how to fix the failing windows build. |
|
Looks like windows is failing (it still is, just there's no asserts) because plugin api version has changed: qemu/qemu@926e146 |
|
Hmm. Hard to know how to fix - qemu now only supports plugin version 2 or higher. But if you wanted to compile a plugin for an older qemu, you'd want to specify version 1 in the plugin you're building. Feature gate it? or maybe keep multilple versions of the API around and let the user declare/use the correct one? maybe const generics? |
|
It was qemu version 9.0.0 that first requires plugin api v2. prior to that (8.2.4) it is v1, and everything is fine. I'll open a separate issue (#15). |
|
If this is ready to go, let's merge this and then I'll worry about the 9.0.0/plugin v2 changes. |
This should fix #13.
calling
libc::freeactually doesn't always work, because there are multiple heaps, and we're trying to free it from the wrong one.Instead, we find the g_free export from libglib-2.0, and invoke that.
Added the
libloadingcrate to help with this, and also rewrote thedelaylink_hookto use the functions there, rather than directly calling the windows API.