NO

Author Topic: Unexpected debugging behavior  (Read 254 times)

Offline Werner

  • Member
  • *
  • Posts: 5
Unexpected debugging behavior
« on: October 05, 2020, 01:09:26 pm »
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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2079
    • http://www.smorgasbordet.com
Re: Unexpected debugging behavior
« Reply #1 on: October 06, 2020, 07:15:26 pm »
"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]
__debugbreak();which will always break in debug builds, but is a no-op in release builds.
/Pelle

Offline Werner

  • Member
  • *
  • Posts: 5
Re: Unexpected debugging behavior
« Reply #2 on: October 08, 2020, 08:19:01 pm »
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]
#include <stdio.h>
#include <stdlib.h>

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

Is this an expected behavior?

Werner

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2079
    • http://www.smorgasbordet.com
Re: Unexpected debugging behavior
« Reply #3 on: October 10, 2020, 07:41:14 pm »
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...
/Pelle

Offline John Z

  • Member
  • *
  • Posts: 104
Re: Unexpected debugging behavior
« Reply #4 on: October 11, 2020, 04:30:54 pm »
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