Application crashing on flush()

[myneni]

Hello,



I am encountering a strange problem with my application which is mixed FORTRAN and C++.



I use Intel FORTRAN and C++ to compile my executable (os.exe) . This executable makes a system() call to another executable (osm_solve; GNU compiled) which loads a DLL (nu.so; also mixed FORTRAN and C++). The DLL is compiled with GNU compilers.



When the executable is built on a RedHAT8 system with Intel 8.1 or 9.0 compilers, the application crashes in the DLL (almost as soon as it is loaded).



When the executable is built on a Fedora Core 2 system with Intel 8.1, the DLL is loaded fine.



Build system (RH8):

/x/u/myneni1>% rpm -qa | grep glibc

glibc-kernheaders-2.4-7.20

glibc-2.3.2-4.80.8

glibc-common-2.3.2-4.80.8

glibc-utils-2.3.2-4.80.8

glibc-devel-2.3.2-4.80.8

/x/u/myneni2>% rpm -qa gcc

gcc-3.2-7

/x/u/myneni3>% uname -a

Linux toucan.tx.altair.com 2.4.20-30.8.legacysmp #1 SMP Fri Feb 20 17:13:00 PST 2004 i686 i686 i386 GNU/Linux

/x/u/myneni4>% cat /etc/issue

Red Hat Linux release 8.0 (Psyche)

Kernel on an m



/x/u/myneni5>%







The following is the trace of the failure. Any help is greatly appreciated. I can try to provide more information if someone can tell me what specifically to look for.



Thanks

-Sachin



>>Program received signal SIGABRT, Aborted.

>>[Switching to Thread -151000352 (LWP 5103)]

>>0x005617a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

>>(gdb) where

>>#0 0x005617a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

>>#1 0x005a0e59 in raise () from /lib/tls/libc.so.6

>>#2 0x005a2882 in abort () from /lib/tls/libc.so.6

>>#3 0x08bb83aa in GetCurrentFrame32 ()

>>#4 0x08bb7c4d in _Unwind_RaiseException_inner ()

>>#5 0x08bbb405 in __cxa_throw ()

>>#6 0x07c42817 in std::__throw_bad_cast () from

>>/usr/lib/libstdc++.so.5

>>#7 0x07c43d7a in std::basic_ios

>std::char_traits >::widen

>>()

>>from /usr/lib/libstdc++.so.5

>>#8 0x07c70ff3 in std::endl > ()

>>from /usr/lib/libstdc++.so.5

>>#9 0x07c6f65f in std::ostream::operator () from

>>/usr/lib/libstdc++.so.5 #10 0x0019c096 in stdapiOut () at

>>../analysis/sendoff.cpp:35

>>#11 0x0019b8e2 in MessageBuf::ScreenOut (this=0x0,

>>message=0x6 ) at

>>../analysis/messagelog.cpp:53

>>#12 0x0019bf1c in MessageLog::p_ToSink (this=0x9695868,

>>message=0x96958c0 " ")

>>at ../analysis/messagelog.cpp:115

>>#13 0x0019b838 in MessageBuf::sync (this=0x691fdc)

>>at ../analysis/messagelog.cpp:20

>>#14 0x07c70b2b in std::ostream::flush () from

>/usr/lib/libstdc++.so.5

>>#15 0x07c7106f in std::flush > ()

>>from /usr/lib/libstdc++.so.5

>>#16 0x07c6f65f in std::ostream::operator () from

>>/usr/lib/libstdc++.so.5 ---Type to continue, or q

>to

>>quit---

>>#17 0x0016a527 in MBS_Model::DisplayHeader (this=0x9694a50)

>>at ../analysis/mbdwriter.cpp:153

>>#18 0x0019ca58 in SendOffTaker::API_SendOffModelBegin (this=0x13ef,

>>source_file=0x921ec60 "os-mbd-fem.fem",

>>target_filename=0x9677170 "os-mbd-fem_osm.xml")

>>at ../analysis/sendoff.cpp:297

>>#19 0x085489a8 in RunNuSolver ()
< br>>>#20 0x08548892 in nusolverdriver_ ()

>>#21 0x08544210 in mbddrv_ ()

>>#22 0x0814dc51 in simdrv_. ()

>>#23 0x081472eb in prp0drv_ ()

>>#24 0x00000000 in ?? ()

>>(gdb)

[TimP]

From your statement that the failure is strange, can we infer that you don't have code in more than one language (or more than one brand of Fortran) operating on the same stream?
I did like RH8 myself, and still have a running installation of it, but it's been a long time since it went off support, so I fear the Intel tools can no longer be considered well tested on it.

[myneni]

Tim,

Yes. That stream is operated upon only by Gnu C++.
The reason why I called the failure strange is because the failure seems to be depend on the where the main executable is built.

Here is my calling sequence:
main.exe -> system(osm_solve.exe) -> dyload(nusolver.so)

The main executable makes a system call to invoke osm_solve.exe. osm_solve.exe uses dyload() to load my shared object.

If main.exe is built on Fedora Core 2 system (ICC=8.1), there is no crash in nusolver.so. If main.exe is built on RedHat8 (ICC=8.0,9.1), nusolver.so crashes with a SIGABRT in flush().

Thanks
-Sachin

[myneni]

Some more information:

nusolver.so has both C++ and FORTRAN in it. All the FORTRAN is compiled with g77.

osm_solve.exe is only C++ Compiled with gcc/g++.

main.exe has C, C++ and FORTRAN in it. Compiled with Intel comilers (tried different versions as mentioned in my previous post).


Thanks
-Sachin

[myneni]

Some more pertinant information.

If the main executable, osm_solve and nusolver.so are built with GCC everything works fine.

If the main executable is built with Intel compilers, then the crash happens in the nusolver.so.

-sachin