generating a list of the current stack at run time

hi, and happy 2021!

just a general question that perhaps the assembled populus could comment on...

i have a customer that swears blind that they are not knowingly using a specific option in our application to write out a 'bloated' copy of their data but the resulting data file says that they must be! the problem is that i can't reproduce it inhouse and the function that performs the operation is called from a variety of places with a plethora of optional flags.

so, what i'd like to be able to do is to generate a stack dump report (like when a runtime error occurs) but not to crash the program, as that would greatly upset the customer!!!

anyone got any 'lightbulb' :idea: ideas on how to do this (i thought that perhaps by adding a line to do a divide/0 and to flag it to be ignored might work - but i'm unsure of the correct way to do that just in the key routine and, even if i did, how could i get the stack listing 'automatically' generated to a text file - or a window on screen that could be captured and sent to me by the customer?)

TIA

K

I don't know of an easy way to do that.

You can't recover from a 'divide by zero' and most exceptions are like that.

Even when you can recover (for example, when you set a break point in your code) you would need to know where in the code to do that.

Even then, how would you do that without the user knowing?

if it was possible to generate the 'report' as a text buffer, i could write that to a debug file and they could send that to me when they noticed the problem had occurred.

I was thinking that there might be a system/salflibc call that is made when a crash occurred that generates the crash window and that could be called directly by me to generate the current stack list in a form that could be pasted into an email.

i already have a modal dialogue set up to be triggered when the 'bloat' occurs but I don't get it triggered inhouse so i can't see what the stack looks like if/when they do...

The only other ways I can think to do it would be:

To set them up with SDBG and tell them how to put a breakpoint in at the offending routine - but that would not look very 'professional'!

or

To just force a crash at the top of the offending routine if they set an INI file environmental variable before starting the program.

K

Does this mean that you know the offending routine but not the path to it?

yes, precisely!

K

Compaq Fortran (two decades ago) and Intel Fortran (currently) provide a subroutine TRACEBACKQQ that serves the purpose quite well. Optional arguments are provided to allow the program to print out a traceback and then continue execution.

See https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/t-to-z/tracebackqq.html .

I have used that subroutine to trap an error related to aliasing of arguments in a large program. There were scores of places in the program from which the subprogram in which the error occurred was called, and the aliasing error occurred only after hundreds of calls that executed normally, so using a symbolic debugger to trap the problem was not really feasible.

Such a subroutine would be a valuable addition to FTN95.

very interesting. Exactly what i'm looking for. i wonder if it would understand the FTN95 stack if it was available in a DLL... 😉 !

K

Quoted from KennyT very interesting. Exactly what i'm looking for. i wonder if it would understand the FTN95 stack if it was available in a DLL... 😉 !

K

For such routines to work, the compiler should issue code that saves and restores the frame pointer (EBP/RBP) values in the stack chain, and the linker should preserve that information when building an EXE or DLL.

Given the prodigious debugging capabilities of FTN95/SLINK, I should think that it should be not that difficult to implement this facility, provided it is established that enough users want it.