Bizarre happenings in VS2005 C

[Ray Mitchell]

Hello,

Have you ever had a program that simply seemed to defy the code it
contained? In my experience I've only seen it a few times and now I'm seeing
it again in one of my VS 2005 C programs (WinXP Pro). I know there must be
something fundamentally wrong in the program overall but I'm at a loss for a
reasonable way to debug it. For example, consider:

FILE *fp;

fp = fopen(rinexFilePath, "r+");
if (fp == NULL) // if file doesn't
exist...
{
if ((fp = fopen(rinexFilePath, "w")) == NULL) // ...create it
{
perror(rinexFilePath);
return 1;
}
}
x = 5;

The file I'm trying to open doesn't exist, so the first fopen fails and
assigns a null pointer into fp. On the next line I test fp so I can attempt
to create the file if it was found not to exist. When I breakpoint with the
debugger at the first "if", it shows that fp is indeed null. However, when I
single-step once more the program jumps to the statement, x = 5;. Just for
laughs I tried "if (!fp)" instead, which should be identical, and it didn't
work properly either.

The same program also sometimes works differently for things like the
following, simply because of the unnecessary braces:

for (whatever1)
for (whatever2)
for (whatever3)
statement;

versus

for (whatever1)
{
for (whatever2)
{
for (whatever3)
{
statement;
}
}
}

I've seen things like this before, including programs that run differently
based upon the names chosen for the variables, the time of day they are run,
and other bizarre things. The problem is that I don't know how to begin
debugging such a thing short of getting into the assembly code itself, which
I really dread doing. Maybe moving to VS2008 or VS2010, crossing my fingers,
and throwing salt over my left shoulder is the most appropriate first
approach. Any ideas?

Thanks,
Ray

[Igor Tandetnik]

Post by Ray Mitchell
The file I'm trying to open doesn't exist, so the first fopen fails
and assigns a null pointer into fp. On the next line I test fp so I
can attempt to create the file if it was found not to exist. When I
breakpoint with the debugger at the first "if", it shows that fp is
indeed null. However, when I single-step once more the program jumps
to the statement, x = 5;.

Are you trying to debug a release build, by any chance? Debugger may behave strangely when presented with optimized code that
doesn't line up with source lines very well. Execution point appearing to jump around wildly is a common symptom.

[Ray Mitchell]

Post by Igor Tandetnik

Post by Ray Mitchell
The file I'm trying to open doesn't exist, so the first fopen fails
and assigns a null pointer into fp. On the next line I test fp so I
can attempt to create the file if it was found not to exist. When I
breakpoint with the debugger at the first "if", it shows that fp is
indeed null. However, when I single-step once more the program jumps
to the statement, x = 5;.

Are you trying to debug a release build, by any chance? Debugger may behave strangely when presented with optimized code that
doesn't line up with source lines very well. Execution point appearing to jump around wildly is a common symptom.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

Igor,

Thanks. Yes, I am aware of the sometimes strange seeming behavior due to
the optimizer. However, in this case the code inside the first "if" never
executes at all. I've put a breakpoint there just to be sure, but it never
happens.

Ray

[Doug Harrison [MVP]]

On Wed, 7 Oct 2009 16:10:02 -0700, Ray Mitchell

Post by Ray Mitchell
Thanks. Yes, I am aware of the sometimes strange seeming behavior due to
the optimizer. However, in this case the code inside the first "if" never
executes at all. I've put a breakpoint there just to be sure, but it never
happens.

Open a mixed source/assembly window and examine the code. If it's present,
then place a breakpoint at the assembly level and see what happens. If it's
absent, you've got bigger problems. In general, I would never trust a
debugger to be a code coverage tool except by single-stepping at the
assembly level.

[Barry Schwarz]

On Wed, 7 Oct 2009 13:16:02 -0700, Ray Mitchell

Post by Ray Mitchell
Hello,
Have you ever had a program that simply seemed to defy the code it
contained? In my experience I've only seen it a few times and now I'm seeing
it again in one of my VS 2005 C programs (WinXP Pro). I know there must be
something fundamentally wrong in the program overall but I'm at a loss for a

It might help us help you if you posted a reasonably short
**compilable** example that illustrates the unexpected behavior.

[Ray Mitchell]

Post by Barry Schwarz
On Wed, 7 Oct 2009 13:16:02 -0700, Ray Mitchell

Post by Ray Mitchell
Hello,
Have you ever had a program that simply seemed to defy the code it
contained? In my experience I've only seen it a few times and now I'm seeing
it again in one of my VS 2005 C programs (WinXP Pro). I know there must be
something fundamentally wrong in the program overall but I'm at a loss for a

It might help us help you if you posted a reasonably short
**compilable** example that illustrates the unexpected behavior.
--
Remove del for email

I don't belive that would accomplish anything useful. I've used the code I
did post in many other programs over the years and it's worked perfectly. I
believe the issue here is the fact that the code is part of a much bigger and
more complex program and fails only in that context.

[Scot T Brennecke]

Post by Ray Mitchell

Post by Barry Schwarz
On Wed, 7 Oct 2009 13:16:02 -0700, Ray Mitchell

Post by Ray Mitchell
Hello,
Have you ever had a program that simply seemed to defy the code it
contained? In my experience I've only seen it a few times and now I'm seeing
it again in one of my VS 2005 C programs (WinXP Pro). I know there must be
something fundamentally wrong in the program overall but I'm at a loss for a

It might help us help you if you posted a reasonably short
**compilable** example that illustrates the unexpected behavior.
--
Remove del for email

I don't belive that would accomplish anything useful. I've used the code I
did post in many other programs over the years and it's worked perfectly. I
believe the issue here is the fact that the code is part of a much bigger and
more complex program and fails only in that context.

Then follow Doug's advice and debug it in disassembly view.
Side question: have you installed SP1 for VS 2005?

[Ulrich Eckhardt]

Post by Ray Mitchell
fp = fopen(rinexFilePath, "r+");
if (fp == NULL) // if file doesn't exist...
{

[...code is never reached...]

Classics are

if(fp = NULL) // assignment

and

if(fp==NULL); // empty statement

The latter doesn't explain your observations though. Can you by any other
means than the debugger determine whether the code is executed? I.e. is the
file created if it doesn't exist? That requires of course that you have
suitable rights to create the file...

Uli