1. dll woes

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

new topic     » topic index » view message » categorize

2. Re: dll woes

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: dll woes

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.)

new topic     » goto parent     » topic index » view message » categorize

4. Re: dll woes

irv said...

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.

new topic     » goto parent     » topic index » view message » categorize

5. Re: dll woes

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: dll woes

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: 

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu