Problem with unepexted termination on Snow Leopard

[trobitaille]

Hi,

I recently did a clean install of snow leopard on my machine (i.e. reformatting the hard drive) and reinstalled ifort 11.1 0.67. When running a program, I can no longer interrupt the program with control-c. If I try, the program hangs, but does not return to the prompt and I have to do a 'kill -9' to stop the job. Similarly, if the program reaches a point where it should crash and give a traceback (for example due to a segfault) it just hangs instead of stopping and printing the traceback. Does anyone know what might be going on? I'm using the following flags to compile:

-heap-arrays -check all -warn all -warn nodec -warn interfaces -traceback -g

Thanks for any help,

Thomas Robitaille

[Ron_Green]

Quoting - trobitaille

Hi,

I recently did a clean install of snow leopard on my machine (i.e. reformatting the hard drive) and reinstalled ifort 11.1 0.67. When running a program, I can no longer interrupt the program with control-c. If I try, the program hangs, but does not return to the prompt and I have to do a 'kill -9' to stop the job. Similarly, if the program reaches a point where it should crash and give a traceback (for example due to a segfault) it just hangs instead of stopping and printing the traceback. Does anyone know what might be going on? I'm using the following flags to compile:

-heap-arrays -check all -warn all -warn nodec -warn interfaces -traceback -g

Thanks for any help,

Thomas Robitaille

When you hit Ctrl-C you are physically sitting at the computer, right? You are not logged into the server by ssh or VPN?

Any idea what the program is doing when you try to kill it? are you reading from stdin?

I'll try to reproduce this

[Ron_Green]

Quoting - Ronald W. Green (Intel)

When you hit Ctrl-C you are physically sitting at the computer, right? You are not logged into the server by ssh or VPN?

Any idea what the program is doing when you try to kill it? are you reading from stdin?

I'll try to reproduce this

nmicl-lab10:~ super$ ifort -heap-arrays -check all -warn all -warn nodec -traceback -g foo.f90 -o foo
nmicl-lab10:~ super$ ./foo
^Cforrtl: error (69): process interrupted (SIGINT)

[trobitaille]

Quoting - Ronald W. Green (Intel)

When you hit Ctrl-C you are physically sitting at the computer, right? You are not logged into the server by ssh or VPN?

Any idea what the program is doing when you try to kill it? are you reading from stdin?

I'll try to reproduce this

I'm sitting at the compute physically, and this happens at any point. I've managed to narrow it down to happening when I link to a specific library. For example if I take the following code

program test
do
end do
end program test

and compile it with

ifort loop.f90 -L/usr/local/lib/ -lcfitsio

then run

./a.out

if I try control-c-ing the process it will hang. If I compile with

ifort loop.f90

then I can terminate it without a problem. If I try with a different library, e.g.:

ifort loop.f90 -L/usr/local/lib/ -lpgplot

then again the program will hang if interrupted, so it doesn't seem to be dependent on the specific library used. This is all despite the code not actually containing any calls to the library. I also do not have this problem with f95, gfortran, or g95.

Best regards,

Thomas

[trobitaille]

Quoting - Ronald W. Green (Intel)

nmicl-lab10:~ super$ ifort -heap-arrays -check all -warn all -warn nodec -traceback -g foo.f90 -o foo
nmicl-lab10:~ super$ ./foo
^Cforrtl: error (69): process interrupted (SIGINT)

I forgot to mention in the first post that I was linking to a library - see my previous post

[trobitaille]

Just to add a bit of info, in case it helps - if I compile with

ifort -m32 loop.f90 -L/usr/local/lib/ -lpgplot

then I can terminate the process. If I compile with

ifort -m64 loop.f90 -L/usr/local/lib/ -lpgplot

I cannot (a.out hangs). The libraries I'm trying to link against are 32/64bit, e.g:

/usr/local/lib/libpgplot.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libpgplot.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libpgplot.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Best regards,

Thomas

[trobitaille]

Just for info, I managed to reproduce the problem on another mac running snow leopard. What could be causing this?

Cheers,

Thomas

[Ron_Green]

Quoting - trobitaille

Just for info, I managed to reproduce the problem on another mac running snow leopard. What could be causing this?

Cheers,

Thomas

Thomas,

I am not sure what could be causing this behavior. It is clear that linking in the 64bit version of pgplot causes the signal handling to be altered. Why the 32bit pgplot doesn't have the same behavior is baffling.

At the start of a Fortran program, the Fortran runtime library sets up signal handlers to trap certain signals, such as SIGINT (sent to the program from the user Ctrl-C). Various device drivers are used in PGPLOT, and these drivers do have signal handlers that they set up AFTER the Fortran main starts up - for things like arrow keys, and refresh control keys. These will override the Fortran defaults. I think it's possible that somewhere in PGPLOT, SIGINT is set up to be trapped by PGPLOT - maybe on purpose, maybe by mistake.

If you build PGPLOT yourself, you might try reducing the number of devices to the bare minimum you need. This may avoid the problem by avoiding a device driver that is set up to capture SIGINT. I still cannot understand why the 32bit version would not behave the same, though. But it is clear that something in the 64bit PGPLOT library you are using is overriding the Fortran runtime default signal handling.

ron

[trobitaille]

Quoting - Ronald W. Green (Intel)

Thomas,

I am not sure what could be causing this behavior. It is clear that linking in the 64bit version of pgplot causes the signal handling to be altered. Why the 32bit pgplot doesn't have the same behavior is baffling.

At the start of a Fortran program, the Fortran runtime library sets up signal handlers to trap certain signals, such as SIGINT (sent to the program from the user Ctrl-C). Various device drivers are used in PGPLOT, and these drivers do have signal handlers that they set up AFTER the Fortran main starts up - for things like arrow keys, and refresh control keys. These will override the Fortran defaults. I think it's possible that somewhere in PGPLOT, SIGINT is set up to be trapped by PGPLOT - maybe on purpose, maybe by mistake.

If you build PGPLOT yourself, you might try reducing the number of devices to the bare minimum you need. This may avoid the problem by avoiding a device driver that is set up to capture SIGINT. I still cannot understand why the 32bit version would not behave the same, though. But it is clear that something in the 64bit PGPLOT library you are using is overriding the Fortran runtime default signal handling.

ron

I compiled PGPLOT myself and it only includes the EPS drivers. However, I don't think PGPLOT is intrinsically the problem - as I pointed out, the problem occurs even if I compile with a completely separate library such as CFITSIO. I even tried linking with the GCC libraries, and this also causes a problem! For example

ifort loop.f90 -L/usr/local/lib -lgcc

produces a binary a.out that will hang if I send a control-c signal.

What could be causing this?

Thanks,

Thomas

[Ron_Green]

Quoting - trobitaille

Quoting - Ronald W. Green (Intel)

Thomas,

I am not sure what could be causing this behavior. It is clear that linking in the 64bit version of pgplot causes the signal handling to be altered. Why the 32bit pgplot doesn't have the same behavior is baffling.

At the start of a Fortran program, the Fortran runtime library sets up signal handlers to trap certain signals, such as SIGINT (sent to the program from the user Ctrl-C). Various device drivers are used in PGPLOT, and these drivers do have signal handlers that they set up AFTER the Fortran main starts up - for things like arrow keys, and refresh control keys. These will override the Fortran defaults. I think it's possible that somewhere in PGPLOT, SIGINT is set up to be trapped by PGPLOT - maybe on purpose, maybe by mistake.

If you build PGPLOT yourself, you might try reducing the number of devices to the bare minimum you need. This may avoid the problem by avoiding a device driver that is set up to capture SIGINT. I still cannot understand why the 32bit version would not behave the same, though. But it is clear that something in the 64bit PGPLOT library you are using is overriding the Fortran runtime default signal handling.

ron

I compiled PGPLOT myself and it only includes the EPS drivers. However, I don't think PGPLOT is intrinsically the problem - as I pointed out, the problem occurs even if I compile with a completely separate library such as CFITSIO. I even tried linking with the GCC libraries, and this also causes a problem! For example

ifort loop.f90 -L/usr/local/lib -lgcc

produces a binary a.out that will hang if I send a control-c signal.

What could be causing this?

Thanks,

Thomas

I cannot reproduce what you are seeing:

nmicl-lab10:~ super$ ifort -heap-arrays -check all -warn all -g -traceback -o timef timef.f90 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -lgcc -m64
nmicl-lab10:~ super$ ./timef
^Cforrtl: error (69): process interrupted (SIGINT)
nmicl-lab10:~ super$

It is odd that I am not getting a stack traceback, which could indicate a bigger bug lurking. Can you try the compilation exactly as I have it above?

What Xcode version are you running - curious about what ld you have:
ld -v
@(#)PROGRAM:ld PROJECT:ld64-95.2.12

This is from Xcode 3.2. I can't remember if this is the Xcode version that comes with the SL install DVD or if I downloaded this version from ADC.

---timef.f90---
program testtimef
USE IFPORT

INTEGER i, j

REAL(8) elapsed_time
j = 0
elapsed_time = TIMEF( )

DO i = 1, 1000000000

j = j + 1

END DO

elapsed_time = TIMEF( )

PRINT *, elapsed_time

END

[trobitaille]

[removed duplicate post]

[trobitaille]

Quoting - Ronald W. Green (Intel)

I cannot reproduce what you are seeing:

nmicl-lab10:~ super$ ifort -heap-arrays -check all -warn all -g -traceback -o timef timef.f90 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -lgcc -m64
nmicl-lab10:~ super$ ./timef
^Cforrtl: error (69): process interrupted (SIGINT)
nmicl-lab10:~ super$

It is odd that I am not getting a stack traceback, which could indicate a bigger bug lurking. Can you try the compilation exactly as I have it above?

What Xcode version are you running - curious about what ld you have:
ld -v
@(#)PROGRAM:ld PROJECT:ld64-95.2.12

This is from Xcode 3.2. I can't remember if this is the Xcode version that comes with the SL install DVD or if I downloaded this version from ADC.

---timef.f90---
program testtimef
USE IFPORT

INTEGER i, j

REAL(8) elapsed_time
j = 0
elapsed_time = TIMEF( )

DO i = 1, 1000000000

j = j + 1

END DO

elapsed_time = TIMEF( )

PRINT *, elapsed_time

END

I tried what you suggested and it worked fine (I could interrupt the job). I tried

valinor:tmp tom$ ifort -O0 -o timef timef.f90 -L/usr/lib

and I could also interrupted. I then tried

valinor:tmp tom$ ifort -O0 -o timef timef.f90 -L/usr/local/lib

and suddenly I can't interrupt it anymore, and it hangs.

Does this offer any clues?

Thomas

[Ron_Green]

Quoting - trobitaille

I tried what you suggested and it worked fine (I could interrupt the job). I tried

valinor:tmp tom$ ifort -O0 -o timef timef.f90 -L/usr/lib

and I could also interrupted. I then tried

valinor:tmp tom$ ifort -O0 -o timef timef.f90 -L/usr/local/lib

and suddenly I can't interrupt it anymore, and it hangs.

Does this offer any clues?

Thomas

Yes, I may have an idea. In an earlier post it appeared that you have a gcc installed in /usr/local/lib, perhaps one that you config'ed and built from source. The Intel compiler uses multiple gcc libraries to assist the Fortran runtime system. It's possible that during the linking you're picking up libgcc from /usr/local/lib rather than the default gcc installed by Xcode. Try this:

$ otool -L timef
timef:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1)

and see where libgcc is coming from. If it is your libgcc, then maybe during the config forgot something. What did you do about threads in the config command?

ron

[trobitaille]

Quoting - Ronald W. Green (Intel)

Yes, I may have an idea. In an earlier post it appeared that you have a gcc installed in /usr/local/lib, perhaps one that you config'ed and built from source. The Intel compiler uses multiple gcc libraries to assist the Fortran runtime system. It's possible that during the linking you're picking up libgcc from /usr/local/lib rather than the default gcc installed by Xcode. Try this:

$ otool -L timef
timef:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1)

and see where libgcc is coming from. If it is your libgcc, then maybe during the config forgot something. What did you do about threads in the config command?

ron

I think that's it:

timef:
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1)

However I didn't install/compile gcc myself - all I installed was a pre-built version of gfortran from

http://r.research.att.com/tools/

but inspecting the package it appears that this was what installed /usr/local/lib/libgcc_s.1.dylib

What's the best way to solve this issue without changing the gfortran issue?

Thanks,

Thomas

[Ron_Green]

Quoting - trobitaille

I think that's it:

timef:
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1)

However I didn't install/compile gcc myself - all I installed was a pre-built version of gfortran from

http://r.research.att.com/tools/

but inspecting the package it appears that this was what installed /usr/local/lib/libgcc_s.1.dylib

What's the best way to solve this issue without changing the gfortran issue?

Thanks,

Thomas

You'll want to make sure that /usr/lib path comes before /usr/local/lib in your DYLD_LIBRARY_PATH environment variable when you are using Intel Fortran. The gfortran may be OK using the libgcc shared lib from /usr/lib.

source /opt/intel/Compiler/11.1/067/bin/ifortvars.sh intel64
export DYLD_LIBRARY_PATH=/usr/lib:${DYLD_LIBRARY_PATH}

and then

otool -L timef

and it should be picking up the libgcc from /usr/lib. You can put that in your ~/.profile startup file (create .profile in your home dir if it does not exist. Then add the source and export commands from above.)

Test gfortran and see if it's OK with the libgcc in /usr/lib.

ron