1. dll woes
- Posted by irv Mar 26, 2015
- 1732 views
Can someone either tell me what I am doing wrong here, or confirm that there is a bug?
-- contents of file number1.shared, -- euc -so number1.shared produces number1.so export function call_one() return "This is a message from function n1\n" end function -- contents of number2.shared, -- euc -so number2.shared produces number2.so export function funk_two() return "This is a message from function n2\n" end function
Here is the test program, dlltest.ex:
include std/dll.e atom libx = open_dll("./number1.so") printf(1,"open dll 1 returns %d\n",libx) atom liby = open_dll("./number2.so") printf(1,"open dll 2 returns %d\n",liby) atom fx = define_c_func(libx,"call_one",{},E_SEQUENCE) printf(1,"function call 1 is %d\n",fx) atom fy = define_c_func(liby,"funk_two",{},E_SEQUENCE) printf(1,"function call 2 is %d\n",fy)
Here are the results when running eui dlltest.ex:
open dll 1 returns 27362528
open dll 2 returns 27413312
function call 1 is 19
function call 2 is 20
Error in `eui': double free or corruption (fasttop): 0x00000000019bde60
Aborted
2. Re: dll woes
- Posted by ghaberek (admin) Mar 26, 2015
- 1701 views
Can someone either tell me what I am doing wrong here, or confirm that there is a bug?
I believe I can confirm this is a bug.
If you change the call to dlopen() in be_machine.c (line 2114) to use RTLD_LOCAL instead of RTLD_GLOBAL, the issue goes away. This leads me to believe that the cleanup code in your compiled Euphoria library (put there by the Translator, not you) is freeing something in global memory before all of the references have dropped to zero - hence the "double free" message you're seeing. At least, that's what I've gathered from a cursory Googling of the message and the documentation provided for dlopen().
Is it safe to use RTLD_LOCAL instead of RTLD_GLOBAL? Probably. But I'd say the safest approach is to track down the offending code in the translated library or only use RTLD_LOCAL for translated Euphoria libraries, and use RTLD_GLOBAL for any "foreign" (non-Euphoria) or "native" (C/C++) library. More testing is needed to confirm.
-Greg
3. Re: dll woes
- Posted by irv Mar 28, 2015
- 1578 views
Just to clarify:
Do you think this will only cause problems when both dll's are written in Eu, or could it also cause crashes if one dll was Eu, and your program also calls other dlls written in c, such as GTK *.so or Windows *.dll?
(Yeah, I know I could test, but this dll stuff is unfamiliar to me, I wouldn't know if the problem was some simple coding mistake on my part, or an actual bug in the works.)
4. Re: dll woes
- Posted by jimcbrown (admin) Mar 28, 2015
- 1544 views
Just to clarify:
Do you think this will only cause problems when both dll's are written in Eu, or could it also cause crashes if one dll was Eu, and your program also calls other dlls written in c, such as GTK *.so or Windows *.dll?
(Yeah, I know I could test, but this dll stuff is unfamiliar to me, I wouldn't know if the problem was some simple coding mistake on my part, or an actual bug in the works.)
If Greg's description is correct, this should only affect two Euphoria-compiled shared objects. A regular C-compiled shared object isn't going to know about the global memory in Euphoria, let alone try to free something from it.
5. Re: dll woes
- Posted by ghaberek (admin) Mar 28, 2015
- 1536 views
If Greg's description is correct, this should only affect two Euphoria-compiled shared objects. A regular C-compiled shared object isn't going to know about the global memory in Euphoria, let alone try to free something from it.
That's what I was saying, yes. I can't remember ever trying to use two Euphoria-compiled shared libraries at the same time. Has anyone tested this on Windows as well?
One problem I foresee with using RTLD_LOCAL, is if YourApp load LibraryA and LibraryB, and then LibraryB also loads LibraryA internally, and LibraryA (which, if local, is now a new instance) relies on some global memory constructs, then YourApp and LibraryB will see different sets of information from LibraryA and that could cause some strange conflicts.
That's just a theory, but I believe that's the difference between loading libraries globally versus locally. I hope I'm wrong on that point.
-Greg
6. Re: dll woes
- Posted by cargoan Mar 28, 2015
- 1506 views
I do not know if it will do any good, but it gives me this (calling funcs):
open dll 1 returns 17755760 open dll 2 returns 17521184 function call 1 is 22 and returns This is a message from function n1 function call 2 is 23 and returns This is a message from function n1 *** Error in `eui': munmap_chunk(): invalid pointer: 0x00000000010a12a0 *** Fatal run-time error: