Internal file problem

Tom_S_1 · ‎12-15-2010

Hello,

Consider the following chunk of code:

PROGRAM test

USE, INTRINSIC :: ISO_C_BINDING

IMPLICIT NONE

CHARACTER (len=2) :: string

INTEGER :: i=1_C_INT

WRITE (string,'(I2)') i

WRITE (*, '(A,A)') 'string: ',string

ENDPROGRAM

When running this code on my Mac with ifort 12 update 1, it appears to produce the correct output:

string : 1

However, when running this with valgrind, many errors are produced:

==31668== Memcheck, a memory error detector

==31668== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info

==31668== Command: ./a.out

==31668==

--31668-- ./a.out:

--31668-- dSYM directory has wrong UUID; consider using --dsymutil=yes

==31668== Conditional jump or move depends on uninitialised value(s)

==31668== at 0x10004646B: for__open_proc (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

==31668==

==31668== Conditional jump or move depends on uninitialised value(s)

==31668== at 0x10003078C: for__get_vm (in ./a.out)

==31668== by 0x100046495: for__open_proc (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

==31668==

==31668== Conditional jump or move depends on uninitialised value(s)

==31668== at 0x100068616: __intel_sse2_strcpy (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

==31668==

==31668== Conditional jump or move depends on uninitialised value(s)

==31668== at 0x100028377: for__add_to_lf_table (in ./a.out)

==31668== by 0x1000478D4: for__open_proc (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

... and more...

==31668== Conditional jump or move depends on uninitialised value(s)

==31668== at 0x100068616: __intel_sse2_strcpy (in ./a.out)

==31668== by 0x1000478D4: for__open_proc (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

==31668==

==31668== Use of uninitialised value of size 8

==31668== at 0x100028639: for__add_to_lf_table (in ./a.out)

==31668== by 0x1000478D4: for__open_proc (in ./a.out)

==31668== by 0x10002E4A1: for__open_default (in ./a.out)

==31668== by 0x10003CD5F: for_write_seq_fmt (in ./a.out)

==31668== by 0x10000114E: MAIN__ (in ./a.out)

==31668== by 0x10000105B: main (in ./a.out)

==31668==

string: 1

==31668== Use of uninitialised value of size 8

==31668== at 0x1000286D8: for__rm_from_lf_table (in ./a.out)

==31668== by 0x1000173BF: for__close_proc (in ./a.out)

==31668== by 0x10001C3B5: for__exit_handler (in ./a.out)

==31668== by 0x100022DCD: for_rtl_finish_ (in ./a.out)

==31668== by 0x100001060: main (in ./a.out)

==31668==

==31668== HEAP SUMMARY:

==31668== in use at exit: 352 bytes in 2 blocks

==31668== total heap usage: 14 allocs, 12 frees, 13,829 bytes allocated

==31668==

==31668== LEAK SUMMARY:

==31668== definitely lost: 0 bytes in 0 blocks

==31668== indirectly lost: 0 bytes in 0 blocks

==31668== possibly lost: 0 bytes in 0 blocks

==31668== still reachable: 352 bytes in 2 blocks

==31668== suppressed: 0 bytes in 0 blocks

==31668== Rerun with --leak-check=full to see details of leaked memory

==31668==

==31668== For counts of detected and suppressed errors, rerun with: -v

==31668== Use --track-origins=yes to see where uninitialised values come from

==31668== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 0 from 0)

The problem is that I use essentially the same code in a program of mine, and sometimes, this causes a segmentation fault (which I tracked down with gdb and appeared to be related to the internal file statement).

I tested this with gfortran and this seems not to produce this errors when run through valgrind...

The problem appears to be present with both Mac OS X and Linux ifort compilers...

Any help would be greatly appreciated!

Regards,

Tom

Ron_Green · ‎12-16-2010

Tom,

We see these reports every so often on Valgrind. It seems to have problems with our Fortran Runtime library (FRTL). These are false positives and can be ignored. We QA our FRTL including checking for memory extensively using other tools, so you can simply filter these out.

That it doesn't report the same false positives in other compilers is because their FRTLs are different and use different algorithms.

ron