Not working on mac

[nappa85]

Sorry for the poor title,
I'm using your crate do enable dynamic loading of modules for my application.
It works fine on linux, tested on a physical gentoo and a docker debian 9.3
On OSX 10.13 High SIerra (haven't tested on other versions) it fails with:

rustegram(4467,0x7fffad81d340) malloc: *** error for object 0x106817040: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

The dylib itself is a Rust written lib, and it passes the tests without problems.

[emoon]

Is this when the program is existing or when does it happen? It may be related to this in that case rust-lang/rust#28794

[nappa85]

Sorry, I've not been clear enough...
It panics as soon as I call dylib's exposed function.
There is no TLS on called dylib, it's simple Rust code using serde_json

[emoon]

The issue with the TLS happens even if you just have simple function on mac that just returns a value really but it should only be a problem when unloading. Also you say the tests passes. Do you think you can try to change your dylib to do something similar to what the test is doing (just returning an i32) and see if you get the same issue.

[nappa85]

Ok, i made some tests, those are the function signatures I tested and the results:
pub extern fn test_fun(a: i32) -> i32 OK
pub extern fn test_fun(a; i32) -> serde_json::Value OK
pub extern fn test_fun(a; i32) -> Result<serde_json::Value, String> OK
pub extern fn test_fun(a; &str, b: String) -> Result<serde_json::Value, String> FAIL
pub extern fn test_fun(a; String, b: String) -> Result<serde_json::Value, String> FAIL
pub extern fn test_fun(a; &str, b: &str) -> Result<serde_json::Value, String> OK

It doesn't makes sense to me, but a String parameter is the party stopper.

[emoon]

Are you really sure it's valid to return Rust values in this way in over a dll border? I would guess the problem here is that the String is allocated inside the dll which has a own "copy" of the allocator and then it tries to gets freed on the Rust non-dll side which a pointer that the application knows nothing about (or the other way around)

In my case I have always made sure that the dll makes and owns it's allocations internally and I never return Rust objects directly and only keeping it using a C API.

[nappa85]

I don't know, I'm not an expert about dylibs.
If the String object is consumed inside the dll, but the application side still thinks it's owning it, yes, it could explain the problem, and it could explain why the problem doesn't appears with tests...
Thank you for your support, sorry for wasting your time.

[emoon]

Yeah I think the problem is that the function will try to free the string on exit but it's the application that has allocated it.

No problem. I think this is a general problem with sending data to dll functions and it should be unrelated to how dynamic_reload works as it doesn't know what is going on inside the dlls.

[emoon]

I will close this issue for now as I don't think it's related to dynamic_reload. If you investigate more and it seems to be the case please re-open or file a new issue.

[nappa85]

Yes, it seems to be OS related, because on linux it was working fine...
Actually I solved passing arguments with &stringvar.clone(), I hope it doesn't create memory leaks

[emoon]

Passing a ref should be fine as it's the sender that owns the memory. I would be very careful with returning Rust objects from the dll tho as it may cause similar issues.