executable hangs, creating a large *.gz file

[Michael_Barkhudarov]

When I run an executable compiled with 11.1.048 FORTRAN compiler from Visual Studio 5 on Windows Vista it hangs right away and creates the file test2.gz in the working directory. The file gets larger very fast if I let it run longer. I terminate it with ^C. If I use a makefile instead, it works fine.

I am not sure if it helps, but the code has openmp directives in it.

Any ideas? Thanks,

Michael

[Steven_L_Intel1]

I am not aware of anything in our product that would create .gz files automatically. What does your application do? What options are in effect when you build with VS? What is the name of your project?

Can you open the gz file and see what is in it?

[Michael_Barkhudarov]

Quoting - Steve Lionel (Intel)

I am not aware of anything in our product that would create .gz files automatically. What does your application do? What options are in effect when you build with VS? What is the name of your project?

Can you open the gz file and see what is in it?

Hi Steve,

The application is a CFD code, checks out a flexlm license, then solves a bunch of equations. Since i do not see any output files, i think it hangs while loading the executables.

some of the options I use are /libs:static /threads /Qopenmp /MD /fp:precise /O3. The same project file running on Windows 32 works fine. There are so many settings in the VS project file properties, not sure which ones you need to know. Can send the project file?

Like I said earlier, using a makefile with many of the same options works fine. I ran depends on the executables created in VS and with the makefile, and there are differences in the order the dynamic libraries are loaded. The VS file has libifcoremd.dll loaded first, while the one created with the makefile has it much futher down the list. Does it help?


Michael

[GVautier]

Helllo

It looks like a memory dump file created by Linux kernel on system error.

If it is run on Windows, perhaps complete memory dump at error is set in "start and recover" options in system properties.

[Michael_Barkhudarov]

Quoting - gvautier

Helllo

It looks like a memory dump file created by Linux kernel on system error.

If it is run on Windows, perhaps complete memory dump at error is set in "start and recover" options in system properties.

It did look like a core dump on Linux or Unix, but it never ends. I wait a few hours, the tst2.gz becomes gigabytes in size. Where on Windows are the 'start and recover' options set?

[Steven_L_Intel1]

This is not a Windows memory dump - Windows doesn't use gz and doesn't dump processes unless you ask it to explicitly.

What in your application is named "test2"? I think your application is doing this, or something you have running on the system. There is nothing in the Intel Fortran product that knows how to create gz files.

[Michael_Barkhudarov]

Quoting - Steve Lionel (Intel)

This is not a Windows memory dump - Windows doesn't use gz and doesn't dump processes unless you ask it to explicitly.

What in your application is named "test2"? I think your application is doing this, or something you have running on the system. There is nothing in the Intel Fortran product that knows how to create gz files.

I am not aware of a test2 file created by the executables. It may be in one of the libraries that we create and it is linked with, I will ask the developers of the libraries.

What baffles me is that it works if I use the make file. Is it something in Visual Studio? By the way, that behavior is the same on two machines, both running Windows Vista.

[Michael_Barkhudarov]

Quoting - Michael Barkhudarov

I am not aware of a test2 file created by the executables. It may be in one of the libraries that we create and it is linked with, I will ask the developers of the libraries.

What baffles me is that it works if I use the make file. Is it something in Visual Studio? By the way, that behavior is the same on two machines, both running Windows Vista.

Another clue, perhaps, is that I have an evaluation installationof Intel's Parallel Studio installed on both machines. I also have both FORTRAN 11 and 9.1 installed.

[gib]

Quoting - Michael Barkhudarov

Another clue, perhaps, is that I have an evaluation installationof Intel's Parallel Studio installed on both machines. I also have both FORTRAN 11 and 9.1 installed.

A virus?

[Michael_Barkhudarov]

Quoting - gib

A virus?

did a full scan, comes clean.

It looks like a 64,000 dollar mystery! I am completely baffled.

[Steven_L_Intel1]

I doubt that the install of Parallel Studio is relevant. You didn't tell me if the name "test2" is used in your application anywhere.

[Michael_Barkhudarov]

Quoting - Steve Lionel (Intel)

I doubt that the install of Parallel Studio is relevant. You didn't tell me if the name "test2" is used in your application anywhere.

Sorry, Steve, but no, the name test2 is not used anywhere on our code.

[Michael_Barkhudarov]

Quoting - Steve Lionel (Intel)

I doubt that the install of Parallel Studio is relevant. You didn't tell me if the name "test2" is used in your application anywhere.

Steve,

I added a print statement as the first operand in the code and it does not even get to it. In other words, none of the FORTRAN code has been executed when the executable hangs. I think it hangs while loading the dynamic libraries, but i can't be sure.

[gib]

Quoting - Michael Barkhudarov

did a full scan, comes clean.

It looks like a 64,000 dollar mystery! I am completely baffled.

A mystery indeed! In your situation I'd probably start cutting down the code, to try to narrow the search down. Initially I'd try chopping off big chunks, until I hit a chunk that changed the behaviour, then I'd zoom in on that one. If the problem you are addressing has a variable size, I'd try reducing it. Etc. The general idea is to try to arrive at the smallest possible program that exhibits the pathological behaviour.

[Michael_Barkhudarov]

Quoting - gib

A mystery indeed! In your situation I'd probably start cutting down the code, to try to narrow the search down. Initially I'd try chopping off big chunks, until I hit a chunk that changed the behaviour, then I'd zoom in on that one. If the problem you are addressing has a variable size, I'd try reducing it. Etc. The general idea is to try to arrive at the smallest possible program that exhibits the pathological behaviour.

I will give it a shot, thank you.

[Michael_Barkhudarov]

Quoting - Michael Barkhudarov

I will give it a shot, thank you.

It started working after i removed the third-party library zlib.lib from the list of source files. It was also present in the linking options, so having it in two places was not necessary. This library is used in the executable to create compressed file output. Still don't know why it was doing what it was doing, but I will leave it at that since it is working.

THank you all for your help.

Michael

[Steven_L_Intel1]

Glad to hear it.