Why no stack trace/line number?

[Izaak_Beekman]

I compiled all object files with -g and -traceback and when I run the following compilation command this is what i get:

[plain]ifort -traceback -sox -I /croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/include -g  -warn all -check bounds -check format -check output_conversion -check pointers -check uninit -prof-gen=srcpos -prof-dir /croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/intelprofile -Dunit_testing -Dno_oop2003 -prof-file modfileio.intel.log   -o TestRunner modfileio_fun.o /croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modfileio.o /croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modtypes.o /croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modioutils.o TestRunner.o
/croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modfileio.o:(.rodata+0x890): multiple definition of `DYNTYPE_PACK_0'
modfileio_fun.o:(.rodata+0x1cc0): first defined here
/croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modfileio.o:(.rodata+0x8a0): multiple definition of `DYNTYPE_PACK_1'
modfileio_fun.o:(.rodata+0x1cd0): first defined here
/croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modfileio.o:(.rodata+0x1250): multiple definition of `DYNTYPE_PACK_2'
modfileio_fun.o:(.rodata+0x1ce0): first defined here
/croccohomes/ibeekman/Sandbox/crocco/postprocessers/cartesian/FPPTC/trunk/src/tests/../modfileio.o:(.rodata+0x1260): multiple definition of `DYNTYPE_PACK_3'
modfileio_fun.o:(.rodata+0x1cf0): first defined here
[/plain]

Does anybody know why this is happening and how i can debug this? I am using fancy 2003 OOP features that are "supported" by ifort 11.1 but am willing to remove OOP code if necessary to fix this.

[Ron_Green]

I am not sure. DYNTYPE_PACK is possibly being brought in by the profiling. If you don't use profiling options, do you still get the error?

From the above, both modfileio.o and modfileio_fun.o have these DYNTYPE_PACK symbols. You can verify with

nm modfileio.o | grep DYNTYPE

they are both probably "T" target symbols. I would guess that you compile those with profiling enabled. It might be interesting to see how you built those object files.

[mecej4]

The simple answer is that -g and -traceback apply to _your_ executable, which was not produced because of linking errors and, therefore, has not been run.

The linker is telling you that you have double instances of DYNTYPE_PACK_0, DYNTYPE_PACK_1 and DYNTYPE_PACK_2 in the file whose compilation produced modfileio.o.

[Izaak_Beekman]

Thanks for the tip. When I look into this tomorrow I'll post my results here and more details of the code compilation. Basically though, the compiler flags are pretty consistent across the object files.

[Izaak_Beekman]

Edit/Update: This problem goes away if I change a Dummy argument declaration from CLASS( ) to TYPE( ), where type is a specific instance of the class. I have a suspicion the profiling isn't playing nicely with the new 2003 OOP features. You guys might want to look into that.


Now to examine the object files produced before this fix:

This is what I get inspecting the object file:

[bash]$ nm -lCa --special-syms modfileio.o | grep DYNTYPE
0000000000000830 R DYNTYPE_PACK_0
0000000000000840 R DYNTYPE_PACK_1
00000000000012b0 R DYNTYPE_PACK_2
00000000000012c0 R DYNTYPE_PACK_3
0000000000001d20 R DYNTYPE_PACK_4
0000000000001d30 R DYNTYPE_PACK_5
0000000000002280 R DYNTYPE_PACK_6
0000000000002290 R DYNTYPE_PACK_7
[/bash]

When I look at it using objdump this is some of what i see:

[bash]$ objdump -trsWGa modfileio.o | grep DYNTYPE
0000000000000830 g     O .rodata        0000000000000010 DYNTYPE_PACK_0
0000000000000840 g     O .rodata        0000000000000010 DYNTYPE_PACK_1
00000000000012b0 g     O .rodata        0000000000000010 DYNTYPE_PACK_2
00000000000012c0 g     O .rodata        0000000000000010 DYNTYPE_PACK_3
0000000000001d20 g     O .rodata        0000000000000010 DYNTYPE_PACK_4
0000000000001d30 g     O .rodata        0000000000000010 DYNTYPE_PACK_5
0000000000002280 g     O .rodata        0000000000000010 DYNTYPE_PACK_6
0000000000002290 g     O .rodata        0000000000000010 DYNTYPE_PACK_7
0000000000000838 R_X86_64_64       DYNTYPE_PACK_1
00000000000012b8 R_X86_64_64       DYNTYPE_PACK_3
0000000000001d28 R_X86_64_64       DYNTYPE_PACK_5
0000000000002288 R_X86_64_64       DYNTYPE_PACK_7
[/bash]

I'm not sure if this provides any insight for you, but as I am not a computer scientist, the only thing it tells me is that DYNTYP* is read only.

I'm going to keep experimenting, I'll let you know what I find.