Problem with idb + -check on osX snow leopard?

[Dalton_Harvie]

Hi,

I recently upgraded to snow leopard and a new version of ifort.

When compiling this test program using the -check flag and then running it through idb the debugger crashes (see screen output below). If the -check flag is not used then idb has no problems. Either way the program runs fine without using idb. Making small changes to the program can remove the error - it took me a long time to pair down a larger code to get this small test code that still exhibits the problem.

Using osX 10.6.2 and ifort 11.1.080 intel64 (idb version 11.1 build 1.2097.2.319).

I tried the same code on osX 10.4 and ifort 11.0.056 intel64 (idb version 11.0 build 1.1510.2.69) and idb gave no errors - maybe I'm missing something simple but it looks like a problem with idb?

I think it may be related to the problems found by the user in this thread:Huge Memory Difference between 32 bit (5.6 MB) vs 64 bit (4 GB) Build

[fortran]program test

double precision, dimension(:), allocatable :: rhs
double precision, dimension(:), allocatable :: a
integer, dimension(:), allocatable :: icn, irn
double precision, dimension(:), allocatable :: w
integer, dimension(:,:), allocatable :: ikeep,iw
integer :: n, i

n = 100

allocate (rhs(n),a(n),irn(n),icn(n),w(n),ikeep(n,5),iw(n,8))

do i=1,n
  a(i) = 1.d0    ! removing any one of these statements causes the idb error to disappear
  icn(i) = i
  irn(i) = i
  rhs(i) = 10.d0
end do

deallocate (w,ikeep,iw,a,rhs,icn,irn)

end program test
                           [/fortran]

Screen output:

[bash]bilby:test> make clean
rm -f test *.o *.mod make.log
bilby:test> make
ifort -c -g -check test.f90 2>> make.log -o test.o
ifort -o test -g -check test.o  2>> make.log
bilby:test> cat make.log
bilby:test> idb ./test
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.319]
------------------
object file name: ./test
Reading symbols from /Users/daltonh/fortran/arb/test/test...done.
(idb) run
Starting program: /Users/daltonh/fortran/arb/test/test
iidb(302) malloc: *** error for object 0x100000000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Intel Debugger for applications running on Intel 64, Version 11.1 caught signal "Abort trap" (6).
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.

terminate called after throwing an instance of 'FatalError'
Abort
bilby:test>
bilby:test> ifort -logo
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1    Build 2009
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.[/bash]

[chauvjo]

I beileve this is due to a compiler bug (Bug report ID: DPD200149111). Maybe Ron Green can gives an update on whether this bug will be fixed in the next update. Check out this thread on more details on a related problem caused by the same problem.

http://software.intel.com/en-us/forums/showthread.php?t=71015&o=d&s=lr

[Steven_L_Intel1]

DPD200149111 is not yet fixed but I don't see the connection with this issue.

[Dalton_Harvie]

Has anyone been able to reproduce this behaviour? I can't see anything wrong with the program but I may be missing something.

Also, where are details of DPD200149111 given?

Thanks.

[Kevin_D_Intel]

Yes, the idb abort trap is reproducible. I reported this to the IDB development team (see internal tracking id below) and will post any other work around besides not using any of the following:

1. -check
2. -check all
3. -check bounds -check uninit -check pointers

Avoiding the minimum combo in item 3 above allows the program to be debugged. You can successfully use any of those three individually or no more than two together.

(Internal tracking id: DPD200149584 - idb Abort trap: malloc: pointer being freed was not allocated)

This is not related to the abort trap that occurs when using -traceback with ifort 11.1 and Xcode 3.2 under Mac OS X (10.6.2) that is at the heart of the earlier thread chauvjo cited (here) and the associated internal tracking id DPD200149111. The details of DPD200149111 are not available externally. And while not related, the -traceback issue will hamper using -check options.

I just subsequently discovered a more general issue with tracebacksfor cases where this succeeds whereit is not properly symbolized.

For example, given the following sample.f90

[bash]program sample
integer i
i =j
write(*,*)"i =",i
end[/bash]

When compiled as shown below, while the traceback succeedsit is not symbolized with line number/source fileinformation.

[plain]$ ifort -g -V -save-temps -check all -traceback sample.f90 -o sample
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1    Build 20091130 Package ID: m_cprof_p_11.1.080
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.

 Intel Fortran 11.1-2649
@(#)PROGRAM:ld  PROJECT:ld64-95.2.12
Library search paths:
        /opt/intel/Compiler/11.1/080/lib
        /opt/intel/Compiler/11.1/080/Frameworks/mkl/lib/em64t
        /opt/intel/Compiler/11.1/080/lib
        /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/
        /usr/lib/i686-apple-darwin10/4.2.1/
        /usr/lib/
        /opt/intel/Compiler/11.1/080/lib/
        /opt/intel/Compiler/11.1/080/Frameworks/mkl/lib/em64t/
        /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
        /usr/lib/gcc/i686-apple-darwin10/4.2.1/
        /usr/lib/i686-apple-darwin10/4.2.1
        /usr/lib
        /usr/lib
        /usr/local/lib
Framework search paths:
        /Library/Frameworks/
        /System/Library/Frameworks/

$ ./sample
forrtl: severe (193): Run-Time Check Failure. The variable 'sample_$J' is being used without being defined
Image              PC                Routine            Line        Source      
sample             000000010006DEFC  Unknown               Unknown  Unknown
sample             000000010006CA34  Unknown               Unknown  Unknown
Unknown            000000010080726B  Unknown               Unknown  Unknown
[/plain]

[Dalton_Harvie]

Thanks for following this up. Look forward to update.

[Kevin_D_Intel]

Development can only fix this idb issue in the next major debugger release tentatively scheduled for late this year. The complexity prevents fixing in 11.1 so please continue using one of the earlier suggested work arounds. Sorry for the inconvenience.

(Resolution Update on 3/11/2010):Internal tracking id DPD200149111 referenced in the -traceback defect details above is fixed in the Intel Fortran Compiler Professional Edition 11.1 Update 5 (11.1.069 - Linux)