Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28383 Discussions

TracebackQQ fails depending on code not executed yet

Benjamin_D_2
Beginner
240 Views
It looks like the compiler generates invalid code either in the tracebackQQ function or when a complex constant is embedded into the code. This seems to affect the x86 compiler only, and in Debug mode only. However, it does not depend on whether the debugger is actually running. Minimal working example:
program BreakIt
   use ifcore
   
   implicit none
   
   print *, "Before traceback"
   call tracebackQQ(user_exit_code = -1)
   print *, "After traceback"
   read *
   print *, (0d0, 0d0)
end program
Compiler command line (just the standard settings of a new project)
/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc140.pdb" /traceback /check:bounds
/check:stack /libs:dll /threads /dbglibs /c
Linker command line
/OUT:"Debug\Console2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\Console2.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"(path)\Debug\Console2.pdb" /SUBSYSTEM:CONSOLE
/IMPLIB:"(path)\Debug\Console2.lib"
What happens in x86 Debug mode is that "Before traceback" is printed. Then tracebackQQ is called, which triggers an access violation in libifcoremdd.dll. After that, the debugger issues another breakpoint (it hits an INT 3 statement) and execution terminates with "STATUS_STACK_BUFFER_OVERRUN encountered". The cause for this exception seems to be the print statement of the complex number (which is never executed - even if no error occurs, read would prevent the execution without explicit confirmation). If this print line is commented out, the code works as it should, giving a proper traceback. The problem is not related to the print function, this was just an example - it seems to be related to the complex constant (0d0, 0d0), which, when present does something "bad". Indeed, the example I gave is somewhat different from what I had in my code. It was more like the following:
program BreakIt
   use ifcore
   
   implicit none
   
   print *, "Before traceback"
   call tracebackQQ(user_exit_code = -1)
   print *, "After traceback"
   read *
   print *, getCmplx()
   
   contains
      complex(8) function getCmplx()
      end function
end program
So a function returns a complex value (which is not set here to keep it most simple, but the function is not called anyway. I want to show that not necessarily the constant itself is a problem, but something is wrong with the complex type.) The same problem of above arises. It also happens for complex(4), but not for integer or real(8). I would also like to know whether the use of the complex data type is the problem and tracebackQQ did reveal it (but it could occur also in circumstances where it is unlikely to spot its cause) - which is a big problem -, or whether tracebackQQ is actually the buggy one (which is then not so severe, for this method is not used too often).
0 Kudos
0 Replies
Reply