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 

Program crash no matter what

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



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Nov 11, 2014 12:40 am    Post subject: Program crash no matter what Reply with quote

I had a program crash and this time, clicking "Details" actually showed something. Program is too big to post, but thought I could post the crash details. I am stumped. I've snipped the screen shots an put them here. As beast I can tell, it occurs in the SALFLIBC.DLL in a call to the routine named WSF1##.
It matters not what code is at line 94. It always crashes right there with an access violation.







Any help or advise on further debugging I should do would be most appreciated.
Bill
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Nov 11, 2014 12:47 am    Post subject: Reply with quote

Just on a lark, I tried something else.

If I remove all of the INTERFACE definitions, it appears to work without error. I will continue with this. I onoly used the INTERFACE definitions as a help to find coding errors that weren't showing up until run-time.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 11, 2014 7:56 am    Post subject: Reply with quote

If you are not already doing so then you should use the CHECKMATE option on the FTN95 command line. Also use the debugger SDBG to run programs that fail.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Nov 11, 2014 5:16 pm    Post subject: Reply with quote

Paul, I've been doing that (Checkmate WIN32). But I'm not finding all the argument type/length mismatches during the compile phase. So I have devolved into a manual matching process. This was more of a heads-up just in case someone else had this class of problem.

And before folks offer extra advice on type/length compatibility, the files used/created by this code have to be compatible with the user's original data, some of which dates back to the mid-1980's. So, before I make the final plunge, I have to absolutely guarantee and test file compatibility which includes binary direct access file where data size/typing matching is paramount.

So, I'm going slow to make sure of full compatibility (even if it means manually slogging through all the files and interfaces and where they are used). I knew the process would be long when I started.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Nov 11, 2014 5:36 pm    Post subject: Reply with quote

Quote:
But I'm not finding all the argument type/length mismatches during the compile phase. So I have devolved into a manual matching process.
When subprograms and source code files are compiled the compiler cannot check outside the scope of the current source file. In fact, a subroutine developed today may be compiled and added to an object library, which is used years later by someone else. The compiler cannot check against potential mistakes before they are committed!

However, FTN95 excels at finding mismatches at run time. Therefore, the heroic manual matching process is neither necessary nor effective.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Nov 11, 2014 6:48 pm    Post subject: Reply with quote

mecej4: In those instances of SW debug where there is a file to be read and much processing to occur, then running a file (or files) against the code is a great way to have FTN95 find subtle errors.

Quote:
However, FTN95 excels at finding mismatches at run time. Therefore, the heroic manual matching process is neither necessary nor effective.


What you do not know is this code is manual entry oriented. There is no input file since, for the user, the original records are on paper.

That means that to get to the place where the error occurred may take anywhere between 10 and 500 keystrokes. So, subtle type mismatches that cause a "crash" are even more labor intensive than you may have imagined.

And changes due to this "new" compiler add an additional level of complexity. It is a good thing, since a few deeply buried bugs have been uncovered. But getting to the end is, and will continue to be, a long manual process.
Back to top
View user's profile Send private message Visit poster's website
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