Re: Stack corruption and memory leak problems in c++/Fortran application

Anndy wrote:
On Oct 31, 3:31 pm, glen herrmannsfeldt <g...@xxxxxxxxxxxxxxxx> wrote:
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.


I tried with increasing the stack size in compiler options, but
problem remains the same.

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?


Yes, This same thing I tried by creating a small application where i
am calling
a fortran subroutine from C++. In this sample I have not written any
code and subroutine
takes no argument. Here also i am seeing this 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.

This i have already checked everywhere in my application. In every
call I am passing
the same size variables. I have also checked in fortran code for
receiving the correct
values in respective variables.

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

Regarding calling convention/Order of arguments on the stack i need
references.
i have no idea about this.


This is a wild guess:

The type of strlen() is 'size_t' instead of 'int'. On a 64-bit system, strlen(code_menu) could be using eight bytes.

Fortran could be expecting a 4-byte string length as the last argument. On a little-endian system like a PC, the string length is in the first four bytes, so the subroutine sees the right value. However, when the subroutine exits, it cuts back the stack as if the string length had used only four bytes, and the high order four bytes of the string length are being left on the stack. This could be why you're seeing increments of four bytes of memory usage and an eventual stack overflow.

The solution? Verify that C++ uses only four bytes for 'int' (i.e., print 'sizeof(int)'), and write your own wrapper for strlen():

int fortran_strlen(const char *s)
{
return strlen(s); /* you may have to write int(strlen(s)) */
}

Then change your C++ code slightly, like this:

const char code_menu[] = {"ANNDY"};
/* 'const' isn't necessary, but it's a good thing to do for a
string that's not supposed to change */

FUNC(code_menu, &ibid, &nufen, &nuws, &ierr,
fortran_strlen(code_menu));

*If* this works, and if you're trying to use the same C++ source for Windows and HPUX, you might have to do something like this:

#ifdef HPUX
typedef size_t fortran_strlen_u;
#else
typedef int fortran_strlen_u;
#endif

....

fortran_strlen_u fortran_strlen(const char *s)
....

Louis

Louis
.

Relevant Pages

  • Re: f95 OOP question
    ... and I managed to bring the intel compiler to its knees. ... until you understand Fortran 95 a little better. ... The term module means the same thing in Fortran 95 that it does in every other computer programming language. ...
    (comp.lang.fortran)
  • Bug in IBM Fortran compiler?
    ... while trying to compile an application with the IBM Fortran compiler I ... "Add" subroutine, but I just found that the assignment ...
    (comp.lang.fortran)
  • Re: Latest on Windoze Navy software
    ... > it had defined a proper string type like Fortran and Basic, ... Well, I haven't used Fortran since F77, but base don that your now ... but because programmers don't really care. ... many 1979 BSD 4.0 systems do you think had any compiler other than the C ...
    (comp.os.vms)
  • Re: Several questions about character C binding
    ... the following simplified interface works too: ... Fortran standard term "dummy argument" and the C Standard term "formal ... string lengths in there. ... end subroutine read_hidden ...
    (comp.lang.fortran)
  • Re: beginners question
    ... If you pass a literal to a subroutine, the compiler puts the ... literal into a temporary variable and passes a reference to that ... Also, since FORTRAN was developed at a time when memory was very tight, ...
    (comp.lang.perl.misc)