Scientific Linux 4.5 and Portland

Dear all,

I tryied PGI 616 and 713 compilers on a Scientific Linux 4.5 (Scientific Linux is a porting of RedHat Enterprise 4.5) running on a Dell Precision Xeon 5120 with 2GB RAM. I compile a fortran program without problem, but during the execution the program stops.

If I use -fast FLAG (the default) in the compilation, the program exit with
0: ALLOCATE: 2665758560 bytes requested; not enough memory

If I remove -fast and put -O0, the program exit with:
*** glibc detected *** double free or corruption (!prev): 0x08a6c788 ***
./Run2: line 4: 17165 Aborted /prog/cyana <<EOF

I use the PGI compilers (616) in another old machine (running Gentoo) and the same program works fine, so I think that the problem is the distribution or its old libraries (glibc 2.3.4-2.36). But SL should be more ‘standard’ than Gentoo.

What can I do to compile my programs to run properly in this distro?

Thanks
Enrico Morelli

Hi Enrico,

Did you try to unlimit the stacksize before running? Perhaps it is stacksize issue.

Hongyon

Thanks for your answer.

If the command is

ulimit -S -s unlimited

yes, I done.

Hi,

How do you allocate your memory that large? Did you try with -mcmodel=medium?

Can you provide us a small test case of your program that fails? If you cannot post it here, please e-mail to trs@pgroup.com and describe detail.

Thank you,
Hongyon

I don’t try the flag (I’ll try) and I cannot post a small test case because the program is a licensed fortran program to calculate protein structure and it’s a big program with a lot of input files.

The problem is that the same program compiled with PGI 616 in a Gentoo PC (PIV 3.6GHz 2GB RAM) works fine with the same input files. If I simple copy the executable in the new machine, I have the problem described above. The problem was not solved also if I compile the program under the new machine using the 616 and 713 PGI compiler.

Another big problem is that we buyed a new cluster that use the same distribution and if the programs doens’t works…

The PGI 713 compiler give me the error:

pgf90-Error-Unknown switch: -mcmodel=medium

The same program works fine using g95 fortran compiler (www.g95.org).

But I would find a solution to use PGI because I have a license for it and I would use it.

Hi,

Are you using 32-bit compiler? Is this 32-bit application? If not, can you try 64-bit compiler. Is your new cluster 64-bit cluster? I am trying to narrow down why it works with g95, perhaps it is 64-bit compiler. I still think it is memory issue and perhaps got lucky in 616 on Gentoo.

As for example program: I am not asking to post the whole program here, but if you can provide where the test fail to allocate memory when compile with -fast and write a simple program and send to trs@pgroup.com. Perhaps we can help find a problem faster.

Hongyon

I’m using the 32-bit compiler. If I try to use the 64-bit I receive
-bash: /opt/pgi/linux86-64/7.1-3/bin/pgf90: cannot execute binary file


For the program, I don’t know fortran so well to write a program to simulate the error. Sorry.

Hi,

I am not sure why you got that message about a compiler. If it is 32-bit cluster, then it would not install 64-bit compiler at all. This is 32-bit cluster, right?

What is the formal program you run? Perhaps there are some users out there know what the problem is. Sometimes it is just a configuration issue.

Hongyon

Yes is a 32-bit cluster.

The program is cyana.

Hi,

It might help if you contact CYANA folks directly. Perhaps they have experience with it and know what the issue is.

Hongyon

Ok. But I think that the problem is related to compiler and OS because I ever used PGI to compile the programs running on our clusters starting from RedHat to Gentoo and every compilation and program worked fine.

Now I change the OS and the program doesn’t work. It isn’t a program problem because, as I wrote, the same program compiled with PGI works fine under Gentoo.

Hi,

Unfortunately we do not have CYANA to test on Scientific Linux OS. Perhaps contacting CYANA or Scientific Linux directly might give a clue of what could be a problem.

Hongyon