Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28519 Discussions

Win32 version works but x64 version crashes

rforehan
Beginner
318 Views

The win32 version of my static library works fine, but the x64 version crashes on a simple assignment of a passed in character string to a global character string in a module.

The main subroutine is in file modfull.f:

SUBROUTINE modfull(..........., dbpath)
USE ISO_C_BINDING
USE OoModtran
character*(*), intent(IN) :: dbpath

! other declarations

dataDirectory = dbpath <---- crash occurs here

!rest of code
END

The module is defined in file OoModtran.f90:

MODULE OoModtran
USE ISO_C_BINDING
IMPLICIT NONE
character*512 dataDirectory
SAVE :: dataDirectory
! other interface and function definitions
END MODULE

In 32bit version, dataDirectory is resolved and assigned the string. In 64bit version, dataDirectory can't be resolved and crash occurs on bad access attempt. I attached the project file for the library.

Thanks for any insight,

Dick

0 Kudos
5 Replies
Steven_L_Intel1
Employee
318 Views
The ZIP you attached contains only the .vfproj file. Please submit a complete test case to Intel Premier Support and we'll take a look.
0 Kudos
rforehan
Beginner
318 Views

Steve,

Sorry about that, I was hoping there was just a bad setting or two for the x64 versions in the project file. I built a small test case, but it doesn't exhibit the problem. I was looking at the differences in the project files between the test case and my app. Inoticed that my app was using the dll runtime libs and not the static runtime libs. The Fortran code was originally set up to generate a dll that was used by a C++ dll. I couldn't get the x64 dll to load so I decided to try generating a static lib instead. The Fortran project property configuration type is grayed out in the dialog (unlike a C++ project) so I couldn't just change it from the dialog. I edited the vsproj file to change to a static lib andmust not havechanged the runtime library setting.

I went back to my project and switched to the static runtime libs. I generated a new static lib, but when I try to link it into my C++ dll, I get the following link errors:

1>Linking...
1> Creating library D:OpticksTAJ211CodeBuildx64DebugModFullModFull.lib and object D:OpticksTAJ211CodeBuildx64DebugModFullModFull.exp
1>libifcoremt.lib(for_diags_intel.obj) : error LNK2019: unresolved external symbol _iob referenced in function for__issue_diagnostic
1>libifcoremt.lib(for_nt_open_proc.obj) : error LNK2001: unresolved external symbol _iob
1>libmmt.lib(libm_error.obj) : error LNK2001: unresolved external symbol _iob
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __argv referenced in function for_rtl_init_
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __argc referenced in function for_rtl_init_
1>D:OpticksTAJ211CodeBuildBinaries-x64-DebugPlugInsModFull.dll : fatal error LNK1120: 3 unresolved externals

I wasn't getting these errors when using the dll runtime libs.

Thanks for any help - I'm getting so frustrated by this project I'm about ready to pitch the computer out the window and join a commune.

Dick

0 Kudos
Steven_L_Intel1
Employee
318 Views
You must make sure that the Fortran and C++ projects have the same setting for the type of run-time library to use (debug vs. non-debug, static vs. DLL, threaded vs. non-threaded.)
0 Kudos
rforehan
Beginner
318 Views

Steve,

Thanks. I went back to using the dll runtime libs and looked more into why the code was crashing on a simple assignment. I could see the contents of the global dataDirectory and the passed in dbpath in debugger. I could run LEN_TRIM on dbpath and get the correct string length. I could assign a local string into dataDirectory. When I tried TRIM on dbpath, I got a stack overflow. The light bulb went off - the subroutine interface takes way too many arguments (5 float*, 13 int, 7 float, 2 int*, 1 char*). The interface contains numerous pointers. Nobody ever bothered to stuff them into a structure and just pass the structure. I'm wondering if the 32 bit works ok and the 64 bit bombs due to the extra 4 bytes in each 64 bit address taking up too much stack space. The default is to use the stack for temp arrays. Does the operation of assigning one chararacter array to another use a temp array?

For a test, I commented out most of the parameter list and the assignment executed without a crash.

Is the best method to define the structure in a module and then just use the module to expose the definition in the subroutine interface block?

Thanks,

Dick

0 Kudos
Steven_L_Intel1
Employee
318 Views
Assigning character arrays ought not to use a temp. Are you getting a stack overflow?

Is this character variable imported from a DLL? Since it is a mixed-language application, are you sure that all address objects are declared the proper size?
0 Kudos
Reply