Broken traceback in Mac OS X 10.7.1 with ifort 12.0.5.209 and Xcode 4.1.1

[forcpp]

Intel official documents say that the ifort Version 12.0.5.209 Build 20110719 supports Mac OS* X 10.7 now supported with Xcode* 4.1.

BUT, the new ifort has broken traceback with Mac OS X 10.7.1 and Xcode 4.4.1. I installed ifort only for command line. Since traceback infos are very essential to find out bug in the programs, your kind attention is very much needed.

For a particular error in a code which I know where is, the traceback is not giving the location of the error instead it is giving the following info:

forrtl: severe (408): fort: (2): Subscript #1 of the array ENTLEG has value 4 which is greater than the upper bound of 3

Image PC Routine Line Source

Stack trace terminated abnormally.

make: *** [test] Error 152

[mecej4]

Errant code (for example, code with subscript errors) is apt to clobber the traceback information if the wrong subscripts cause writes to addresses that overlap the area where the traceback information is stored.

Fix the subscript errors as best as you can until you recover the traceback capability. You may use the debugger or insert PRINT statements in your code to help locate the problem.

[Kevin_D_Intel]

I confirmed -traceback is not working again with the Intel Fortran Composer XE 2011 and Xcode 4.1. With -traceback, the stack trace terminates abnormally and without -traceback the traceback is provided but it is not symbolized with source file and line number information.

I was unable to find a convenient work around. I will report this to Development and update the thread when I know more.

(Internal tracking ids: DPD200173457, DPD200175075)

(Resolution Update on 10/17/2014): This defect is fixed in the Intel® Fortran Composer XE 2013 SP1 Update 2 release (Version 14.0.2.139 Build 20140121 - OS X)

[martinotte]

It looks like with OSX LION, we need to add -Wl,-no_pie to the command line to get stack traces to work. This may also be necessary when debugging code with idb/gdb. I have added this to the ifort.cfg file so that it is the default for me.

[Kevin_D_Intel]

Thank you for sharing your finding. I will discuss this with the Developers. It is unclear whether this would be the final solution. According to the ld man page, asserting this reverts to a pre-10.7 setting which may not be desired. I'll post again after I learn more.

[Kevin_D_Intel]

Our Developers identified that Lion (10.7.1) introduced address-space layout randomization (ASLR) as a security feature and that this affects the "_trace" section of our traceback code where pointers are not updated accordingly and this leads to the segV.

The earlier suggestion to use "-Wl,-no_pie" should be considered a work around.

I'll update again when I learn more.

[moortgatgmail_com]

Any updates on this issue? OS 10.7.5 + Xcode 4.3.2 + ifort 12.1.4 still seems to have this same problem. 

[Kevin_D_Intel]

I apologize. I never saw your post from over a year ago. I just recently retested the original test case associated with the internal tracking ids mentioned in my earlier post and confirmed the traceback issues were fixed earlier this year in the Composer XE 2013 SP1 Update  2 (Version 14.0.2.139 Build 20140121 - OS X*) release.