windows 7 - Segmentation fault when calling a Delphi function from Fortran -

i have fortran 90 program repeatedly calls on delphi function. function gets called large number of times program quits segmentation fault.

i have executable of code compiled ibm fortran works fine, , have recompile whole thing using gfortran

i have source code of main program, not of function, lives in dll supplied code, , boreland dll presumably supports delphi bits: borlndmm.dll

the dll 32 bit , working on windows 7 sytem, 32bit gfortran compiler specs:

 collect_gcc=c:\program files (x86)\gcc\bin\gfortran.exe collect_lto_wrapper=c:/program files (x86)/gcc/bin/../libexec/gcc/i686-pc-mingw32/4.7.2/lto-wrapper.exe target: i686-pc-mingw32 configured with: ../gcc-4.7.2-mingw/configure --host=i686-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=i686-pc-mi    ngw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.7.2 --with-gcc --with-gnu-as --with-gnu-ld --wi    th-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog --with-gmp=/home/gfortran/gcc-home/binary/mingw32/nat    ive/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mpc=/home/gfortran/gcc-home/b    inary/mingw32/native/x86_32/mpc --enable-cloog-backend=ppl --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x8    6_32/gcc/4.7.2 --disable-shared --disable-nls --disable-tls --disable-win32-registry --enable-libquadmath-support --enabl    e-libquadmath --enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32 --enable-lto --enable-static --ena    ble-shared=lto-plugin --enable-plugins --with-host-libstdcxx='-lstdc++ -lsupc++ -lm' --with-ppl=/home/gfortran/gcc-home/b    inary/mingw32/native/x86_32/ppl --enable-ld=yes thread model: win32 gcc version 4.7.2 (gcc) 

i've posted question code (see segmentation fault when calling c function fortran repeatedly) first stumbling block.

i compile code with

 >> gfortran -o cmod cmod.f90  -fbounds-check -ffree-line-length-none -dh -mrtd -g -l. clues.dll 

but can't dump output when fails. thinking have problem memory alignment when calling delphi function, kills me. or may not compiling correctly 32 bit on 64 bit system, don't have experience this. idea on how proceed welcome.

the function definition in original fortran code ibm fortran is:

module overseer  use kernel32  interface    function cluesovr(scenario,region,soilorder,topography,rainfall,asoildepth,snumdairy,snumsheep,snumbeef,snumdeer,additionalnitrogen,supplementrate,supplementtype,nloss,ploss,errstr)    !dec$ attributes  value :: scenario,region,soilorder,topography,rainfall,asoildepth,snumdairy,snumsheep,snumbeef,snumdeer,additionalnitrogen,supplementrate,supplementtype    !dec$ attributes  reference :: nloss,ploss,errstr    logical cluesovr    integer*4 scenario,region,soilorder,topography,asoildepth    real*8 rainfall,snumdairy,snumsheep,snumbeef,snumdeer    real*8 additionalnitrogen,supplementrate    integer*4 supplementtype    real*8 nloss,ploss    character errstr(40)    end function cluesovr  end interface end module 

which have translated to:

interface  logical (c_bool) function cluesovr(scenario,region,soilorder,topography,rainfall, &     asoildepth,snumdairy,snumsheep,snumbeef,snumdeer,additionalnitrogen, &     supplementrate, supplementtype,nloss,ploss, &     errstr) bind (c, name='cluesovr')     use, intrinsic :: iso_c_binding     implicit none     integer (c_int), intent(in), value :: scenario,region,soilorder,topography,asoildepth     real (c_double), intent(in), value :: rainfall,snumdairy,snumsheep,snumbeef,snumdeer     real (c_double), intent(in), value :: additionalnitrogen,supplementrate     integer (c_int), intent(in), value :: supplementtype     real (c_double), intent(out) :: nloss,ploss     character(c_char), intent(out) :: errstr(*)   end function cluesovr end interface 

the ibm code uses

 pointer (q,cluesovr)  p = loadlibrary("cluesovr.dll")  q = getprocaddress(p, "cluesovr") 

to access function. don't gfortran.

the presence of borlandmm.dll suggests task close impossible. dll used allow different modules (e.g. executable , dll) share common delphi memory manager. allows 1 module, executable say, allocate delphi string, , pass other module, dll say, in turn can deallocate string.

unless both modules share same heap, such architecture cannot work. borlandmm.dll library makes heap sharing across modules possible. dll wishes use delphi memory manager of host includes sharemem unit in turn uses borlandmm.dll library effect memory manager sharing.

now, fortran host cannot possibly meet required contract. thing can provide delphi memory manager delphi host. happening dll call believes responsible freeing memory passed. dll receives delphi string variables heap allocated. when dll attempts free memory, memory allocated in fortran host process. , mismatch leading access violations. these not occur every time call function.

the design of dll, use borlandmm.dll reasonable provided expected called delphi host. if developer of dll knew doing have been aware of restriction. fact have got no documentation dll suggests me you've extracted dll program , trying use in way in not designed. chances of success exceptionally low.