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

Louis Krupp <lkrupp@xxxxxxxxxxxxxxxxxxxxxxx> writes:

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.

Interesting. ISTR that on Win64 sizeof(size_t) < sizeof(int) ... you
might be on to something there.

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England
.

Relevant Pages

  • Re: c++ calling c functions
    ... You miss my point - you're telling the C++ compiler to generate C ... less implementation-specific than calling C from C. ... The reason is that neither Fortran, nor Pascal, nor Ada state ... Python states how to interface with C routines, ...
    (comp.lang.c)
  • Re: A question on Newtons Method
    ... >> I can't believe you'd advise a noob to use a compiler which is still ... > production codes and codes from textbooks. ... > The Fortran standard generally does not specify the required behavior ... >> another important class of hassle which most numerical programmers ...
    (sci.math.num-analysis)
  • Fortran Resources (July 2004)
    ... and the standard for the Fortran language and its derivatives. ... WHERE CAN I OBTAIN A FORTRAN 95 COMPILER? ... Absoft Fortran compilers, debuggers, and development tools for Windows, ... are available for Linux systems. ...
    (comp.lang.fortran)
  • Fortran Resources (August 2004)
    ... and the standard for the Fortran language and its derivatives. ... Absoft Fortran compilers, debuggers, and development tools for Windows, ... and Linux include source-compatible Fortran 95 compiler suites ... are available for Linux systems. ...
    (comp.lang.fortran)
  • Fortran Resources (Last Issue)
    ... the, then, new Fortran 90. ... and the standard for the Fortran language and its derivatives. ... WHERE CAN I OBTAIN A FORTRAN 95 COMPILER? ... The Fortran Company offers F, the subset language, for Unix and Windows, ...
    (comp.lang.fortran)