cannot use SUNDIALS-KINSOL in FORTRAN subroutine? - fortran

Question

Thank you for having a look at this problem.
Problem:
seg. fault when returning from f90 subroutine that contains KINSOL solving process, after the correct computation result has been generated. No problem when the same solving process is in the main program.
Environment:
linux,
gcc,
sundials static libs
How to initiate the problem:
get the attached REDUCED test code
module moduleNonlinearSolve
integer,save::nEq
contains
subroutine solveNonlinear(u)
double precision::u(*)
integer iout(15),ier
double precision rout(2),koefScal(nEq)
koefScal(:)=1d0
call fnvinits(3,nEq,ier)
call fkinmalloc(iout,rout,ier)
call fkinspgmr(50,10,ier)
call fkinsol(u,1,koefScal,koefScal,ier)
call fkinfree()
do i=1,nEq
write(*,*),i,u(i)
end do
end subroutine
end module
subroutine fkfun(u,fval,ier)
use moduleNonlinearSolve
double precision::u(*)
double precision::fval(*)
integer::ier
forall(i=2:nEq-1)
fval(i)=-u(i-1)+2d0*u(i)-u(i+1)-1d0
end forall
fval(1)=u(1)+2d0*u(1)-u(2)-1d0
fval(nEq)=-u(nEq-1)+2d0*u(nEq)+u(nEq)-1d0
ier=0
end subroutine
program test
use moduleNonLinearSolve
double precision u(10)
nEq=size(u)
u(:)=10d0
call solveNonlinear(u)
end program``
compile
$ gfortran -c -Wall -g test.f90
$ gfortran -Wall -g -o test test.o -lsundials_fkinsol -lsundials_fnvecserial -lsundials_kinsol -lsundials_nvecserial -llapack -lblas
run
$ ./test
Note: It would work flawlessly if put all the SUNDIALS procedures in the main program.
Thank you very much for any input.
Mianzhi

Answer 1

According to the KINSOL documentation, the first argument of fkinmalloc must be of the same integer type as the C type long int. In your case, long int is 8 bytes long, but you are passing in an array of 4 byte integers. This will lead to fkinmalloc trying to write beyond the bounds of the array, and into some other memory. This typically leads to memory corruption, which has symptoms just like what you are observing: Crash at some random later point, such as when returning from a function. You should be able to confirm this by running the program through valgrind, which will probably report invalid writes of size 8. Anyway, replacing
integer :: iout(15)
with
integer*8 :: iout(15)
should solve the problem.