sdbg source path problems (again)

I have previously reported a problem with sdbg not displaying source code if the original path at build time no longer exists (even if source code with the same filename exists in the same directory as sdbg). The problem was fixed, and incident #s 29204 and 31996 refer. When I subsequently asked for clarification about which path is used, when source is present in both the build location and the location sdbg is invoked from, I received the following unambiguous specification:

'The original source location is checked and, if present, used. If the original source file does not exist then the current directory is checked. The current directory is the directory from which sdbg is invoked. If a source file with the same name as the original source file is found it is used.'

In which case, the fix seems to have been unfixed again :mad: I am using FTN95 v4.8.0 and sdbg v1.98, both dated 4 April 2005, and am having the same problem again. If the build-time source path does not exist, sdbg displays an error message in the middle of the intended source window ('Error opening file: the device is not ready' on Win9x and 'Source file path not valid' on Win2k), with the fully-justified path of the first source file it tries and fails to find in the title bar.

Andy

Robert,

I can only conclude one of two things: either we're using different builds of FTN95 v4.8.0 and sdbg v1.98 😉 , or you haven't checked on anything other than WinXP (and that not very thoroughly). With an app + source code + sdbg in one directory, and the original source code directory renamed, (and using the FTN95-installed copy of sdbg for options 1-3, and the local copy for option 4), here is what I find on three different OSs:

*Nothing *works on Win2k or Win9x.

On WinXP, options 2&3 'work', but display the original path in the title bar rather than the path pointed to by the environment variables ; option 4 works on WinXP with or without the /sp.

Since WinXP is what I have at home, Win2k is what I use at work, and Win9x or occasionally Win2k is what I have to support, this is not satisfactory (particularly since into the bargain it is a regression from previously fixed). I could reluctantly accept it if it didn't work by design on Win9x any more (albeit I would be amazed); but Win2k? 😕

Andy

Did you manage to make any progress on this yet, Robert?

Did you manage to make any progress on this yet, Robert?

Helloo-oo! Anything to report yet, please?

Sorry for the delay. I don;t have a Windows 2000 PC in my office, so I am having to get hold of one to try. I am currently installing Windows 2000 via Virtual PC -- which could be a really valuable tool for regression testing of this type.

Administrator Silverfrost Forums

Hi Robert,

Sorry for delay, I had been waiting for notification that the topic had received a response and for some reason one never arrived - I just noticed your response when I had an ever-hopeful look in the forum anyway. I'm at home now but I'll investigate tomorrow. My paths often do have spaces in, and the one that's causing the issue certainly does. If it is spaces, then we have certainly been here before. I'll get back to you.

Andy

Robert,

I don't want to concern myself with the /sourcepath option, I want sdbg to work correctly without its having to refer to environment variables. Yes, it looks like spaces are the source of the problem. Haven't retested under Win9x yet or WinXP, but under Win 2k here is what I did:

• I temporarily renamed the development source path (to make it 'not present');
• I copied exe, source and sdbg to a new folder at the end of an 'installation' path;

and here is what I found:

1. If installation path has spaces in it, sdbg source window displays 'source path not valid', with original development source path in title bar;
2. If installation path has no spaces in it, sdbg source window displays source, with installation source path in title bar

Both of which seem to be consistent with what is supposed to happen, namely:

'The original source location is checked and, if present, used. If the original source file does not exist then the current directory is checked. The current directory is the directory from which sdbg is invoked. If a source file with the same name as the original source file is found it is used.'

except that a) does not work if the current directory has spaces.

There is a nuance, however. I named the development path back to its original name (which includes spaces), and sdbg works again: if the development path exists it is found and used, even if it has spaces. Under these circumstances, the current directory bug is latent: the issue with spaces only seems to be an issue for the current directory.

I'll recheck behaviour under WinXP tonight and under Win9x tomorrow if I get an opportunity.

Andy

Thanks for experimental version. Hmm ... after some uzzlement, I conclude that you have fixed the spaces issue, and brought another 'feature' into sharper relief in the process. I am still getting an error message I never saw before (I was getting it yesterday when I was investigating the current release version of sdbg, but couldn't quite figure out how to do so reproducibly; I have, now). The error message reads as follows:

<Title bar>Problem loading program</Title bar> 'The file executed may not match the one you intended to debug. This maybe (sic) because there is a copy of your program on the Windows path and it has been loaded in preference to a local one'

Here are my observations with the experimental version of sdbg (still confined to Win2k ATM). They are weird; are you sitting down? The issue now seems to revolve around whether the alternative location is the same as it was when it was first created, not whether it has spaces or not. However, there has been progress inasmuch as case 2a) now functions correctly:

1. Original source path present:

• 1. alternative location is unrenamed (and has spaces in path): sdbg loads original source and is happy.
• 2. alternative location is renamed (and may or may not have spaces in path): I get the weird error, sdbg loads original source and flags (File modified) after the path in the source window title bar

2. Original source path not present:

• 1. alternative location is unrenamed (and has spaces in path): sdbg loads alternative source and is happy.
• 2. alternative location is renamed (and may or may not have spaces in path): I get the weird error, sdbg loads alternative source and flags (File modified) after the path in the source window title bar

I tested my hypothesis about sdbg somehow remembering the original name of the alternative location, and it checks out, and it has nothing to do with spaces. I created another alternative location without spaces in the path, and copied sdbg and alternative source to it. As long as I don't rename that folder, sdbg functions as it is supposed to: it picks up the original source if the development path exists, and the alternative source if the development path does not exist. However, if I rename the folder, even eschewing spaces, I get the error, sdbg loads whichever source is appropriate and flags it as (File Modified). If I name the folder back again, sdbg once again functions as it is supposed to.

It is as if every copy of sdbg is somehow keeping a record of where it was when it was first run and referring back to it subsequently!?!

Andy

(ref my most recent message abou extreme weirdness) To confirm that I see exactly the same behaviour under WinXP Home edition as well now. Andy

Did you try the debugger I sent?

Administrator Silverfrost Forums

Yes, that was the debugger I was referring to in my most recent postings. I thought that would have been clear from the opening lines:

Thanks for experimental version. Hmm ... after some uzzlement, I conclude that you have fixed the spaces issue, and brought another 'feature' into sharper relief in the process. I am still getting an error message I never saw before (I was getting it yesterday when I was investigating the current release version of sdbg, but couldn't quite figure out how to do so reproducibly; I have, now). The error message reads as follows ...

Perhaps you didn't see that posting?

Andy