I also don't have this problem in xHarbour but compiling my module in Harbour solved some other problems for me. To be fair, my xHarbour version is fairly outdated.
So far I manage to recreate the problem when dynamically loading keylib32.dll (a dll from SoftwareKey). Still chopping my test code further so could get a reduced self-contained sample.
Thanks for the tip about hb_gcall().
Anyone has a snippet on how to use the native hb_libload() in Harbour? Seems it's expecting 2 parameters instead of 1
hb_libLoad( PHB_ITEM pLibName, PHB_ITEM pArgs )
. I was wondering whether it would help due to this note in Harbour's changelog
2008-10-13 20:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/rdd/wacore.c
; updated comments about Xbase++ behavior in dbRelease()
* harbour/include/hbvm.h
* harbour/source/vm/hvm.c
* harbour/source/vm/dynlibhb.c
* harbour/source/vm/runner.c
! added MT protection for HB_LIBLOAD()/HB_LIBFREE() and
HB_HRBLOAD()/HB_HRBUNLOAD(). Please remember that you should
not use any external LoadLibrary() functions because they are
not protected for clean PCODE modules loading/unloading even
in ST mode. Using them can cause HVM internal structure corruption.
If we have such functions in contrib then they should be redirected
to our HVM ones.
There is still one problem in MT mode which has to be resolved yet.
When dynamic library containing PCODE using static variables
is loaded 1-st time then it will force resizing of internal array
with static variables. If in exactly the same moment some other
thread operates on static variable then it may cause corruption.
To resolve this problem we will have to divide continuous memory
block common for all modules where we store all static variables
into separated blocks bound with each PCODE module (symbol table).
