forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

generating a list of the current stack at run time

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
KennyT



Joined: 02 Aug 2005
Posts: 285

PostPosted: Mon Jan 04, 2021 11:17 am    Post subject: generating a list of the current stack at run time Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6692
Location: Salford, UK

PostPosted: Mon Jan 04, 2021 12:34 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 285

PostPosted: Mon Jan 04, 2021 1:07 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6692
Location: Salford, UK

PostPosted: Mon Jan 04, 2021 1:25 pm    Post subject: Reply with quote

Does this mean that you know the offending routine but not the path to it?
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 285

PostPosted: Mon Jan 04, 2021 1:30 pm    Post subject: Reply with quote

yes, precisely!

K
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1453

PostPosted: Tue Jan 05, 2021 2:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 285

PostPosted: Tue Jan 05, 2021 2:42 pm    Post subject: Reply with quote

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

K
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1453

PostPosted: Tue Jan 05, 2021 4:06 pm    Post subject: Re: Reply with quote

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

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group