Unexpected debugging behavior

[Werner]

Trying to debug with no breakpoint selected works as expected.

But calling the debugger with an active breakpoint (or with the option "Always break on entry-point" enabled) results in an assembly listing.

On the other hand, even with the option "Always break on entry-point" disabled the debugger breaks right there.

Am I missing any special setting?

(I didn't include a listing because I believe that this behavior is not code-related.)

Werner

[Pelle]

"Always break on entry-point" breaks at the entry-point of the module (startup code), which usually leads to main()/WinMain()/DllMain(), but could possibly lead to something else (for a custom build).

I can't immediately reproduce your other problem.

Not sure it helps, but a completely different approach is to use the breakpoint "statement":

Code Select Expand

__debugbreak();
which will always break in debug builds, but is a no-op in release builds.

[Werner]

Thanks for your response.

The reported issue can be reproduced by the following small program.

- Starting the debugger with no breakpoint set, works fine.

- Starting the debugger with a breakpoint set on the output line (line 7), results in an assembly listing.

Code Select Expand


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
system("dir");
puts("After system().");
return 0;
}


Is this an expected behavior?

Werner

[Pelle]

Thank you for the example. I get the same effect on my machine (Windows 10, version 2004) for this program, but not for other (similar) programs(!).

The debugger apparently receives a request for a breakpoint in cmd.exe, which is where it stops (no source code, so assembly code). If I use "Debug"->"Go", or press F5, the debugger continues to the example program and stops at the breakpoint on puts(), as I expect.

At the moment I don't know if this is a new Microsoft "feature", or what is going on, to be honest...
I will continue to investigate, but unclear when I have an answer...

[John Z]

I ran the test code on a Windows 7 machine with PellesC version 9.  Here is what I found so far.
If I debug the program without ever selecting any debug information I get a notice that there is no debug information then after acknowledging that I get an assembly code display.  The same thing happens regardless of setting a breakpoint or not.

Next I selected debug data on all Project Option pages which have the option to include debug data.
Then debugging the program it shows the same outputs that are being discussed:  Debug with no breakpoint stops at line 4(main entry), then pressing F5 continues and shows assembly listing. Debug with a breakpoint on line 7 skips the stop at line 4 and proceeds immediately to the assembly listing.

This all seems to make some sense to me.  If I'm debugging without breakpoints wouldn't I want the debug to initiate at the start procedure so that I could step thru?  I added a small procedure in front of main then have main call it after puts().  Debug without breakpoint still starts a main.

Caveat is I rarely use debug ( I could not even find "Always break on entry-point" setting) so maybe the only thing of value here is that the debug behavior is the same on windows 7 with PellesC version 9 as it is on windows 10 with PellesC version 10.

John Z