Segfault on stdout OR terminal output WRITE(6,*) ??

[etmeyer]

I am a fairly experienced fortran programmer, but I have never seen this before. Probably because the implimentation here is a little slapped-together, and for a full-fledged project things would be different. Here is the problem:


I have a fairly small optimization routine, in fortran, that is compiled by commands from a perl script. Ultimately this fortran routine is run and the output (a series of WRITE(6,*)) is read in by the perl script through a basic $values = `./a.out stuff...` type command. THis has been working fine for weeks.

I changed a few things (more outputs), and now the program segfaults, seemingly at random (anywhere from 3 - 30 loops will go by running the system command just fine and then one will fail)

WRITE(12,'(/,'' **** RESULTS AFTER SA **** '')')
CALL PRTVEC(XOPT,N,'SOLUTION')
WRITE(12,'(A)')'THIS TEXT DOES NOT CAUSE PROBLEM'
CALL PRTVEC(VM,N,'FINAL STEP LENGTH')
WRITE(12,'(A)')'NOR THIS'
WRITE(12,1001) FOPT, NFCNEV, NACC, NOBDS, T, IER

1000 FORMAT(/,' SIMULATED ANNEALING EXAMPLE',/,&
/,' NUMBER OF PARAMETERS: ',I3,' MAXIMAZATION: ',L5,&
/,' INITIAL TEMP: ', G8.2, ' RT: ',G8.2, ' EPS: ',G8.2,&
/,' NS: ',I3, ' NT: ',I2, ' NEPS: ',I2,&
/,' MAXEVL: ',I10, ' IPRINT: ',I1, ' ISEED1: ',I4,&
' ISEED2: ',I4)
1001 FORMAT(/,' OPTIMAL FUNCTION VALUE: ',G20.13&
/,' NUMBER OF FUNCTION EVALUATIONS: ',I10,&
/,' NUMBER OF ACCEPTED EVALUATIONS: ',I10,&
/,' NUMBER OF OUT OF BOUND EVALUATIONS: ',I10,&
/,' FINAL TEMP: ', G20.13,' IER: ', I3)
WRITE(6,'(I5,X)', ADVANCE='no')CL_INT1
WRITE(6,'(I5,X)', ADVANCE='no')CL_INT2
WRITE(6,'(A)')''


These WRITE(6) statements never get written, and if the fortran is executed from inside the perl I never even hear the error message - it just hangs and when I kill it a.out is still running in the background doing nothing! It just sits! If I take it out on it's own and run it, I get this:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libc.so.6 00007FF84A607E5D Unknown Unknown Unknown
libc.so.6 00007FF84A60A4C9 Unknown Unknown Unknown
libc.so.6 00007FF84A60C7EE Unknown Unknown Unknown
libc.so.6 00007FF84A6648E5 Unknown Unknown Unknown
a.out 000000000044F387 Unknown Unknown Unknown
a.out 000000000041F385 Unknown Unknown Unknown
a.out 000000000043B537 Unknown Unknown Unknown
a.out 0000000000408047 Unknown Unknown Unknown
a.out 000000000040396C Unknown Unknown Unknown
libc.so.6 00007FF84A5B0ABD Unknown Unknown Unknown
a.out 0000000000403869 Unknown Unknown Unknown

I have NO IDEA why this is happening, and all my usual tricks to find where Fortran is unhappy are failing. And this shouldn't be using THAT much memory. The only big thing is the output from the subroutine 'SA' which will happily write a thousand megabyte log file. I don't know if this is related, it hadn't been a problem so far.

[Ron_Green]

Did you try the methods in this article:

http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors/

Keep in mind that WRITE statements are buffered, so often times an application can fault out before the output buffers are flushed. You can try using FLUSH to halt the program and force the flush before proceeding, but typically the -g -traceback mentioned in the above article is more effective.

ron

[etmeyer]

Quoting - Ronald W. Green (Intel)

Did you try the methods in this article:

http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors/

Keep in mind that WRITE statements are buffered, so often times an application can fault out before the output buffers are flushed. You can try using FLUSH to halt the program and force the flush before proceeding, but typically the -g -traceback mentioned in the above article is more effective.

ron

Well, I'm embarassed to say I did not know of the -check bounds option... maybe I should invest some time in reading up on the intel compiler since I am new to it, that solved the issue! The main problem, I suppose, was that the seg fault was not showing up anywhere near to where the problem actually occured. I appreciate the push in the right direction!