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 

file loading error
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Wed Jan 26, 2022 4:38 pm    Post subject: file loading error Reply with quote

When I try to load a compiled file with SDBG I get the message "Failed to open file <name.exe>, code=2"

I have been using SDBG foe some time but have not had this message before.

Any comments/help would be appreciated.

Thanks

alangr
_________________
Alan
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Wed Jan 26, 2022 5:18 pm    Post subject: Reply with quote

That message probably came from SDBGDLL.DLL. Check using utilities such as Tasklist, Taskmgr, etc., whether the EXE that you want to debug is already running from a previous attempt to run the program.

If you find the EXE in a zombie state, kill it, and start the debugging session again.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Thu Jan 27, 2022 4:18 pm    Post subject: Reply with quote

Thanks for your comments. I did not see any thing in a zombie state but I no longer have that problem!

But I do have another issue related to running SDBG as set out below.

C:\A contains files relating to (diagnostic program) A
‘SDBG A’ runs/checks program A and produces A.EXE.

C:\B contains files under development relating to program B.

Wish to use SDBG to run program A to analyse program B.
From directory B, ‘SDBG A B’ fails as the files for A cannot be found so SDBG does not load. Copying all .FOR files in \A to \B does allow execution. But this is messy.

QUERY: how to point SDBG to source files in \A…

I have tried using the SOURCEPATH option of SDBG as suggested in the Silverfrost guide on SDBG, using ‘/SP C:\A’ but
‘SDBG /SP C:\A B’ also does not allow execution with ‘file not found’
Am I doing something silly?

Apologies for the simple issue raised but any help/observations...
_________________
Alan
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Jan 27, 2022 4:38 pm    Post subject: Reply with quote

It is not clear to me what you are aiming to do but I suspect that you need to include the files for B when compiling program A.

A simple way to do this is to use one or more INCLUDE statements in program A.

PROGRAM A
INCLUDE "C:\B\B.for"
....
END PROGRAM A

I don't know if SDBG will allow you to step into the routines in B be you will be able to open the files in SDBG and set break points.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Thu Jan 27, 2022 4:39 pm    Post subject: Reply with quote

Now you have me thoroughly mystified!

"‘SDBG A’ runs/checks program A and produces A.EXE."

SDBG does not produce EXE files, it allows you to debug EXE files that have debug information compiled into them. The compiler and linker are used to produce an EXE from Fortran source files.

"Wish to use SDBG to run program A to analyse program B"

SDBG can only debug one EXE at a time. Running A may give you information that will help fix bugs in B, but A.EXE and B.EXE are independent programs as far as the debugger and OS are concerned. You can run two sessions of SDBG, opening A.EXE in one and B.EXE in the other, switching manually from one session to the other as you please, but the two sessions are still independent.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Fri Jan 28, 2022 10:57 am    Post subject: Reply with quote

First, my apologies for a very poor post. I have been using SDBG since F77, very usefully, but please see below.

I am using program A, compiled and linked in directory A after debugging by SDBG and have been doing so for some time. It is a diagnostic program that I use when developing new programs. At some point last week, when using it with SDBG in another directory, it did not run as I expected. I eventually discovered that the reason it failed to load was the lack of access to the source code for A. I found that if I copied all of the files for A to the directory for the new program, then all worked as before and SDBG ran to debug the new program. So my problem was to see how to set a path to the A code when using A in another directory.

I tried to do this with the SDBG command line option /SOURCEPATH using /SP C:\A but that did not work (ref. https://silverfrost.com/ftn95-help/debug/findingroutines.aspx ). After many different attempts and somewhat frustrated I sent my reply to your response – and made matters worse!

The issue therefore is how to use SDBG with program A to diagnose a new program in a directory other than A and have access the files making up A.

I am working in DOS (no Windows use) and have the PATH set to include directory A. I have not tried using the SET command with environmental variables as I have not used it before.

I also wonder if any recent Windows updates have changed the way that PATHS work (I have been caught with that in the past).

I would be very grateful for any guidance here.

With thanks
_________________
Alan
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Fri Jan 28, 2022 1:51 pm    Post subject: Reply with quote

Act I: There is a directory A with Fortran source files that have been compiled with /DEBUG and linked to produce an EXE, let's call it Aprog.EXE. That EXE file contains the path to the source directory. Therefore, when you enter the one of the commands

Code:
sdbg Aprog
sdbg Aprog.exe


SDBG will open a debugging session on Aprog.exe if it finds the EXE in the current directory or using the path prefix to Aprog.exe if you provided one in the command line, or by searching the list of paths in %PATH%. Since the debugger knows the source path (which is embedded in the EXE), even if the current directory does not contain either the EXE or the source files, the debugger can open the EXE as well as the pertinent source files.

This will fail if, between building Aprog.exe and running it in the debugger, you change the current directory and %PATH% does not contain the directory in which Aprog.exe (and its source files) are located. In this case, using the /SP <pathname> option to SDBG gets things working again.

Act II: You move to a different directory B, which contains some or no files. You now enter the command "sdbg Aprog.exe ". If Aprog.exe is accessible through %PATH%, the command will work. If not, you have to prepend the path to Aprog.exe, and run using the command "sdbg <apath>\Aprog.exe". In either case, SDBG will find and load Aprog.exe from directory A, while retaining B as the current directory. If, however, you have changed the name of the directory A or its location between Acts I and II, things will not work unless you use the /SP option followed by the new name of what used to be directory A.

Finally, about your wish, "The issue therefore is how to use SDBG with program A to diagnose a new program in a directory other than A ...", I have to admit that I still do not understand how your program Aprog.exe can "analyse" or "diagnose" any other program, unless it is endowed with the deep knowledge to interpret the machine code in EXEs and DLLs, not to mention the underlying operating system. However, Aprog.exe can create, delete, read and write data files in directory B, as long as it knows how to do so.

It adds to our confusion that when you say 'A', that can mean "directory A", "the file A.EXE", or "the program that is given the name A in the PROGRAM statement in a source file", and it is not clear from the context which of these you mean. Note that the program name in a Fortran source file has no meaning to the OS, and the relevant EXE need not have inside it any instance of the program name as an embedded or encoded string.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Fri Jan 28, 2022 6:22 pm    Post subject: Reply with quote

Let’s stay with Act 1 and use my filenames. Yes, I have a CALLS directory containing CALLS.FOR and other files. The files are compiled and linked to give CALLS.EXE. The command sdbg CALLS opens a debugging session on CALLS.EXE that runs successfully; all OK and as expected.

You go on to say ”… even if the current directory does not contain either the EXE or the source files, the debugger can open the EXE as well as the pertinent source files.”

This does not happen for me so I wonder what I am not doing. When I go to another directory and enter ‘sdbg CALLS’ I get an access violation with the following:

100049f4 load_program(<ptr>constÄchar,<ptr>constÄchar) [+0274]
10009713 sdbg_main [+0cd3]
00401000 main [+0076]

Further, when I come out of sdbg back into DOS, in the window I get:

Failed to open file calls.exe, code = 2
Failed to open file calls.exe, code = 2

Yes, two lines even though there was only one call to sdbg.

This brings me back to my original query to the forum.
I will not go on to Act II as I guess there is an issue with what is happening in Act I!

Any idea just what is going wrong?

Needless to say, I appreciate your ongoing help very much.
_________________
Alan
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Fri Jan 28, 2022 6:27 pm    Post subject: Reply with quote

Sorry, Paul. I omitted to acknowledge your comments. As I hope you can see from the recent exchanges, I think the problem is more basic than using include (which I use anyway for common blocks).

Thanks for your interest.
_________________
Alan
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Fri Jan 28, 2022 6:45 pm    Post subject: Reply with quote

After changing to a different directory, SDBG will find the previously built EXE only if one of the following conditions is satisfied (quoting myself):

"SDBG will open a debugging session on Calls.exe if it finds the EXE in the current directory or using the path prefix to Calls.exe if you provided one in the command line, or by searching the list of paths in %PATH%."

Based on what you wrote, I think that when you change to directory B, (i) Calls.exe is no longer in the current directory, (ii) %PATH% does not contain the path to directory A, and (iii) you specified only the name Calls without the path prefix to directory A.

You can resolve the problem by fixing at least one of these three deficiencies.

An understanding of the rules for execution paths and search rules for executable files is basic to program development in a command line environment such as Windows CMD or Linux Bash.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Sun Jan 30, 2022 1:26 pm    Post subject: Reply with quote

Thanks. I appreciate your last lines. I can now launch SDBG and CALLS in a directory other than CALLS. As I was still having problems doing so, I deleted the PATH command and re-created it – then all was well. I couldn’t see what was wrong as it looked OK but all seems well now; close curtain (I hope).

Act II is now in focus. I wish to run the CALLS program in another directory and analyse a program in that directory (TRADE). I cannot recall how I used to do this but it was something along the lines of SDBG CALLS TRADE. Now such a call just opens the TRADE program under SDBG.

CALLS goes through a program and lists all subroutine calls and gives a program structure, lists routines not in the directory, etc. TRADE is a developing program with 70+ routines and I am trying to get the CALLS report for TRADE to help me when things go wrong.

I am hoping that you might be able to give me a pointer as to how to do this.

I have been delayed in responding as snow has/is causing power cuts that slow things down (even with a UPS).
_________________
Alan
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Sun Jan 30, 2022 1:51 pm    Post subject: Reply with quote

It seems that TRADES is a directory that contains scores of Fortran source files, which you want your CALLS program to read and generate reports If the CALLS program has already been debugged, and knows how to read and parse the content of the source files in the TRADES directory, you do not need SDBG at all. Simply change to the TRADES directory, and invoke <..path to CALLS.exe> . Or, if it is more convenient, copy CALLS.EXE to the TRADES directory and run it.
I assume that CALLS knows how to scan all the Fortran files in the current directory, or that you help it with a list of source files to process.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Sun Jan 30, 2022 3:41 pm    Post subject: Reply with quote

Yes, TRADE is a directory with all the Fortran files (TRADE.FOR and all subroutines). I agree I do not need SDBG.

Copying CALLS.EXE to \TRADE and then issuing ‘CALLS’ gives a run-time error:

TSTC - in file tstc.for at line 29 [+0225] ] CALLS S/R
GETC - in file getc.for at line 34 [+03e0] [recur= 2] ] CALLS S/R
main - in file calls.for at line 107 [+0ae2] ] CALLS.FOR

CALLS-GETC-TSTC gives the order of subroutine calls encountered in CALLS.

Issuing SDBG CALLS gives no response and a return to a cursor in the DOS window.

Is this progress?

CALLS only gets one parameter, the name of the program to be analysed (TRADE in this case). The batch file that runs CALLS creates an input file for CALLS to read in order to start the analysis. No other file information is provided as the program searches for the next ‘call’ and then carries on and on until it finds a STOP statement.
_________________
Alan
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1707

PostPosted: Sun Jan 30, 2022 4:24 pm    Post subject: Reply with quote

You have shown part of the traceback, but not the error itself. So, you have a program that has bugs, and we do not know much about the program or the data that it is running on.

It is unlikely that anything can be done without having the source, include and data files available for inspection.
Back to top
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 36
Location: Oxford,UK and Athens, Greece

PostPosted: Sun Jan 30, 2022 4:54 pm    Post subject: Reply with quote

That is all of the traceback I have. CALLS compiled OK so I was not expecting any issues there.I have no idea as to how to find the error given that CALLS has a clean bill of health from SDBG! I don't see how the problems are due to TRADE; that is why I tried using SDBG, hoping to find the error.

I am, clearly somewhat frustrated by all this but at least I can debug TRADE even without the CALLS information.

I guess the wisest thing to do is leave it all there.

That said, I really appreciate your patience and help - and especially with your rapid replies. I may try to move forward with this in the future but maybe not!

Thanks again.
_________________
Alan
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 -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
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