"ID" as name of object component confuses IDB, interprets as 'whatis OBJECT%ID'

[Ron_Green]

This is a follow-up thread to this original thread: http://software.intel.com/en-us/forums/showthread.php?t=82265

"print OBJECT.ID" returns the same result as typing "whatis OBJECT.ID".

Same instance as before, I have a large structure with hundreds of variables, the last of which is a character string defined as:

CHARACTER*32 ID

When you type "p OBJECT(1).ID", the debugger returns:

type = character*32

Expected return would be the contents of the character string.

[Ron_Green]

I can't reproduce what you are seeing with 'ID' - which version of the compiler (idb) are you using?

> idbc ./u82483
Intel Debugger for applications running on Intel 64, Version 12.0, Build [74.923.2]
------------------
object file name: ./u82483
Reading symbols from /nfs/var/quad/rwgreen/forums/u82483/u82483...done.
(idb) list 1,20
1 program confuse_an_idb
2 type con
3 character*32 :: a_cat
4 character*32 :: ID
5 end type con
6 type ( con ) :: confuse
7
8 confuse.a_cat = 'Royal confuse a cat team'
9 confuse.ID = 'Fluffy the spoiled house cat'
10
11 write(*,*) "break point here, ", confuse%ID
12
13 end program confuse_an_idb
(idb) break 11
Breakpoint 1 at 0x402bf5: file /nfs/var/quad/rwgreen/forums/u82483/u82483.f90, line 11.
(idb) run
Starting program: /nfs/var/quad/rwgreen/forums/u82483/u82483
[New Thread 47048430751808 (LWP 1340)]
[New Thread 47048430751808 (LWP 1340)]

Breakpoint 1, confuse_an_idb () at /nfs/var/quad/rwgreen/forums/u82483/u82483.f90:11
11 write(*,*) "break point here, ", confuse%ID
(idb) p confuse.id
$1 = "Fluffy the spoiled house cat "
(idb) p confuse.a_cat
$2 = "Royal confuse a cat team "
(idb)

[ereisch]

Hrm, when I create a standalone reproducer, I can't replicate the problem. However, it's consistently reproducable in my main application. I'll have to investigate this further to see if it's a compile flag I'm using, or something else non-debugger related.

Intel Debugger for applications running on IA-32, Version 12.0, Build [1.3842.2.154]

[Ron_Green]

it could be context related also, assuming -g is used in the compilation. For example, we sometimes see idb problems with contained procedures, type-bound procedures, extended types. Context can sometimes trigger a bug.

Since it's returning the type information, I almost suspect -g was missed somewhere, but that's a total guess.

[ereisch]

Ok, was finally able to reproduce it. The problem shows up when the program is linked with C++.

File 1: (Compile with 'ifort -g -c -assume nounderscore idb_test.for')

[bash]      P R O G R A M   I D B _ T E S T
C
      IMPLICIT NONE
C
      STRUCTURE /TEST_ARRAY/
          INTEGER*4       NUM1
          CHARACTER*32    ID
      END STRUCTURE
C
      RECORD /TEST_ARRAY/ OBJECT
      INTEGER*4           NOBJS
      COMMON /CTEST/ OBJECT(1000), NOBJS
C
      NOBJS = 1
      CALL CPP_ROUTINE
C
      OBJECT(NOBJS).NUM1 = 10
      OBJECT(NOBJS).ID = 'OBJECT_DESCRIPTION'
C
      WRITE(*,*) 'EXAMINE HERE'
      END[/bash]

File 2: (Compile with 'g++ -c -g idb_test_cpp.cpp')

[bash]#include 
using namespace std;

extern "C" void cpp_routine() {

    cout << " Running...";
    return;
}[/bash]

Note: The above should be "cout << ....", but the less than signs were mangled by the block quote.

Finally, link the executable with "g++ -o idb_test -Wl,--start-group idb_test.o idb_test_cpp.o IFORTPATH/compiler/lib/ia32/libifport.a IFORTPATH/compiler/lib/ia32/libifcore.a IFORTPATH/compiler/lib/ia32/libimf.a IFORTPATH/compiler/lib/ia32/libirc.a IFORTPATH/compiler/lib/ia32/libirc_s.a -Wl,--end-group -lcurses", where IFORTPATH is the installation path of the Fortran compiler (in this instance version 12.0.1.107, Build 20101116).

We are linking using g++ because in our larger application there are mangled C++ routines which apparently must be linked using the g++ linker rather than the ifort linker to properly resolve the C++ libraries.

When you compile the C++ routine without debugging symbols (but with fortran debugging symbols), the debugger behaves as expected. When you compile the C++ routine with debugging symbols, the debugger produces the "type = character*32" behavior when examining OBJECT(1).ID as previously reported.

[ereisch]

Sorry, forgot to mention g++ version is 4.3.2.

[mecej4]

On Suse 11.4 X64, with Intel Fortran 12.0.3 (IA32 and Intel64), and g++/gcc 4.5.1, I cannot reproduce the problem, when both the Fortran and C++ parts are compiled with -g, and I stepped through the C++ source to verify that it had been compiled with -g.

A. In the "debugger commands" pane:

Breakpoint 1, idb_test () at /home/sham/LANG/idbp.f:20
20 WRITE(*,*) 'EXAMINE HERE'
(idb) p object(1)
$1 = {num1 = 10, id = "OBJECT_DESCRIPTION "}
(idb) p object(1).id
$2 = "OBJECT_DESCRIPTION "
(idb) whatis object(1).id
type = character*32
(idb)

B. In the evaluations pane:

OBJECT(1).ID 0x80b9b84 "OBJECT_DESCRIPTION " character*32

Can you try your example on a machine with a more recent g++ than 4.3.2 ?