program BreakIt use ifcore implicit none print *, "Before traceback" call tracebackQQ(user_exit_code = -1) print *, "After traceback" read * print *, (0d0, 0d0) end programCompiler 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 /cLinker 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 programSo 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).