Re: Stack corruption and memory leak problems in c++/Fortran application
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Wed, 31 Oct 2007 02:31:53 -0800
Anndy wrote:
On Oct 31, 12:47 pm, "Colin Watters"
<qolin.see_signat...@xxxxxxxxxxxxx> wrote:
"Anndy" <see.n...@xxxxxxxxx> wrote
I am facing problem in a Porting project(HP-Unix->Windows XP(64 bit))
where there are lots of C++->Fortran and Fortran->C++ calls.
There are some thousands of files including FORTRAN and C++ code.
After performing few operation which involves lot of FORTRAN->C++ and C
++->FORTRAN calling, application gives stack overflow error or behaves
unexpectedly.
It could just be that the stack is too small.
one more thing which i have noticed is, whenever i am making a call to
a FORTRAN function there is a increase in
application memory by 4Bytes.
You mean 4 bytes each call, that doesn't go away when it returns?
In other words, a memory leak?
compiler c++ : MS Visual Studio 2005 / Compiling for 64 bit
compiler FORTRAN :Intel Fortran Compiler 9.1
The 64-bit issue gets my attention. Having been involved in sorting out the
(relatively easy to spot) problems in our (99.9%) Fortran code when porting
to 64-bit, and knowing that C++ does a lot more with pointers than Fortran,
I would name this as Prime Suspect, in the absense of any other information.
On a 64-bit .exe the pointers have to be stored in 64-bit variables. It may
well be that the C++/Fortran interface code doesn't do this. In which case,
its going to get real tricky.
Or just doesn't do it in exactly the same way.
One way to diagnose if this *IS* the issue: get it working in 32-bit mode
first. I know IVF will compile for either 32-bit or 64-bit depending on
compiler switches, and MSC++ must surely do the same. So use the same PC and
opsys to produce a 32-bit .exe and get the bugs out of that, before
attempting a 64-bit version.
The code what we have is 64bit code and was initially on HP-UX. Its
working fine there without giving any such issues.
Calling between Fortran and C (even worse, C++) raises many issues
that wouldn't otherwise be there. The two compilers have to do many
things in the same way, and everything has to be the appropriate
same size.
for more clarity i am attaching signature of fortran subroutine and
calling of it from C++.
C++ calling fortran Subroutine :
========================================================================
Fortran Subroutine :
subroutine func(mcode,nbtarb,nufen,nuws,error)
character*(*) mcode
integer error,nufen,nuws,nbtarb
Calling From C++ :
void SomeFunc(void){
int type_obj = 1, ibid = 0, nuws = 1, nufen = 1, ierr = 0;
char code_menu[] = {"ANNDY"};
FUNC(code_menu, &ibid, &nufen, &nuws, &ierr, strlen(code_menu)); }
CHARACTER variables are one of the more likely differences.
Some pass the length at the end, others right after the appropriate
argument. Also, is the length 64 bits for a 64 bit compiler, or 32?
They could also be passed by descriptor. Note so likely, but
possible. (VAX/VMS, for one, does it.)
=============================================================================
I also have conformed that in the matter of storage size for data
types in fortran and C++
C++ = Fortran
----------------------------------
int = integer
char = character
float = real
You need to confirm the whole calling convention. Order of arguments
on the stack, or arguments passed in registers. Convention for
CHARACTER variables, and for returning function values.
-- glen
.
- Follow-Ups:
- References:
- Prev by Date: Re: Odd omp_get_wtime()
- Next by Date: Re: Stack corruption and memory leak problems in c++/Fortran application
- Previous by thread: Re: Stack corruption and memory leak problems in c++/Fortran application
- Next by thread: Re: Stack corruption and memory leak problems in c++/Fortran application
- Index(es):
Relevant Pages
|
|
