# Visual C++ debugger is acting weird...

This topic is 3857 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I wrote my own simple XML parser a while back, and today I was playing around with writing a program that used the parser to take the data from an XML file and make it into a tree so that my programs could easily access the data. The parser just needs to be subclassed so that it can do things. I've already tested the parser out, and it works fine. However, my TreeParser subclass does not, so I took Visual C++ 2005 Express into debug mode to try and analyze the problem. For some reason, however, when the debugger gets into the Parse() function, it does not register the XML file as being opened. The whole thing is basically a while (file.good()) loop (file is an ifstream), and the debugger just skips past the loop as it evaluates good() as false. The weird thing is, though, that when running the program normally and inserting a statement inside the loop that prints a phrase to a log file, the log file is updated as expected. Thus, it would appear that when running the program normally, good() evaluates to true; when using the debugger, good() evaluates to false under the same conditions. Is there something about the debugger that makes it not handle ifstreams well or something? What could this possibly be?

##### Share on other sites
I believe Visual C++ uses different working directories when in debug mode, you're file may simply not exist in the relevant directory.

##### Share on other sites
Are you compiling and running in debug mode? Otherwise there are no debug symbols and the debugger is only making a best guess as to where the instruction pointer is with respect to the typed code.

-me

##### Share on other sites
Yesterday, I had a chunk of code like thus:
boost:regex re;///....try{   re.assign("[[:digit:]]*");}catch(<the invalid reg expression exception>){   return -1;}//more code here

I was tracing, and watched the debugger step into the catch, execute the return (but didn't actually return), step out, and keep going...O_o

Quote:
 I believe Visual C++ uses different working directories when in debug mode, you're file may simply not exist in the relevant directory.

If it is a debug build, wouldn't the directories coincide?

##### Share on other sites
Quote:
 Original post by _SigmaI was tracing, and watched the debugger step into the catch, execute the return (but didn't actually return), step out, and keep going...O_o

You can always jump to assembly in those situations to figure out what's actually going on. I've never seen this behavior, however, in a Debug build (i.e. all the symbol generation goodness is turned on, and all the code optimization is turned off).

Sometimes you get freaky stepping with optimization turned on because when optimizing the compiler may take common code out of smaller scopes and pop it up a level of scope or 2. i.e. you'll see some code in the else block executed when it's the then block that's actually executing.

-me

##### Share on other sites
Quote:
 Original post by PalidineAre you compiling and running in debug mode? Otherwise there are no debug symbols and the debugger is only making a best guess as to where the instruction pointer is with respect to the typed code.

Indeed, I'm running the Debug build of my program at all times... I don't even think I compiled a Release build yet. The XML file is in the same directory and does work fine, as I tested it with my original parser that simply prints the data to the screen. Again, though, when stepping through that working parser in debug mode, it skips that while loops entirely, resulting in nothing.

Someone mentioned turning off optimization. How do I do that? Also, if the actual debug process (i.e. stepping through the code) uses a different working directory than the Debug build's .exe, where is this directory given? Given the sort of error that's occuring, it does indeed seem as if it just can't find the file when actually stepping through.

##### Share on other sites
I had a weird problem with good() once.

It would work on some files, but fail on others. Same format, different contents. Renaming, moving, testing, commenting, debugging - all zilch.

Then I restarted the computer, and it's worked.

I never found out what the problem was, but good() simply failed due to internal buffer overrun (or EOF-like condition). What's most puzzling, is that it happened based on contents of the file, yet file was never even read (it failed on first call to good(), or any other attempt to read the file).

To this day I don't know what happened.

##### Share on other sites
It could be a timing issue... putting the process under the debugger will alter the execution speed a little.

Maybe you can trying setting the exception mask on the ifstream such that it throws when something goes wrong? That might point you to the code that makes the stream no longer good() when under the debugger.

##### Share on other sites
Okay, I ran another test, and it seems that when stepping through with the debugger, file.fail() will return true, whereas running the .exe does not. However, the only docs I can find simply say that this means there was an internal logic error with ifstream. What does that mean? Why is this breaking? Should I just use the C method of reading in files instead?

##### Share on other sites
These docs for fail() imply that the badbit flag could be set too (not just failbit).
http://www.cplusplus.com/reference/iostream/ios/fail.html
I take that to mean the file could have been closed or something.

Can you post the code where you open the stream and where it fails?

##### Share on other sites
   ifstream file(filename.c_str());      if (file.eof())   {      logfile.Print("EOF!");   }   if (file.bad())   {      logfile.Print("bad!");   }   if (file.fail())   {      logfile.Print("fail!");   }

"filename" is indeed set properly to the input received, according to the debugger. When stepping through this snippet, it steps into the if (file.fail()) block. However, when running the .exe, the logfile never shows a "fail!" line (and the logfile does get other output that I told it to print, so I know it's not a problem with logfile.).

##### Share on other sites
Well now that looks like it just wasn't able to open the file.

You're sure that filename is an absolute path and the file exists? (if it's just a relative path, that could explain the difference right there - it would suggest the current working directory is different when you run it under the debugger, and the file can't be found)

Well, anyway, assuming you do have an absolute path, you need to find the reason the file is failing to be opened. Unfortunately ifstream doesn't give any indication why. I would temporarily switch it to the win32 api CreateFile. Assuming it also fails in that case, GetLastError() should return the error code that indicates why it failed.

##### Share on other sites
if( !file.is_open() ) {   logfile.Print("Not open!");}

##### Share on other sites
Quote:
 Original post by phil_tWell now that looks like it just wasn't able to open the file.You're sure that filename is an absolute path and the file exists? (if it's just a relative path, that could explain the difference right there - it would suggest the current working directory is different when you run it under the debugger, and the file can't be found)

Aye, both a relative and absolute path fail. I did, however, test !file.is_open(), which returns false when debugging, but true when not. Is there some debug working directory path I can change in the VC++ settings somewhere?

##### Share on other sites
Oh wow.

Nevermind, I just answered my own question. In the project settings, under "Debugging", there's a working directory option that is defaultly set to where the project file is (but my file was in the debug build directory). After changing it, the debugger acts as it should. Still don't know why an absolute path failed... but oh well.

Thank you all for your suggestions and help with this, I appreciate it very much.

##### Share on other sites

This topic is 3857 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.