Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional breakpoint only stops the first time #268

Closed
rei-vilo opened this issue Mar 25, 2021 · 6 comments
Closed

Conditional breakpoint only stops the first time #268

rei-vilo opened this issue Mar 25, 2021 · 6 comments
Assignees
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself topic: debugger Related to the integrated debugger type: imperfection Perceived defect in any part of project

Comments

@rei-vilo
Copy link

rei-vilo commented Mar 25, 2021

Describe the bug

Conditional breakpoint only stops the first time.

Adding i%2 to line 8 only stops the first time when i=1, but not after when i=3 or 5.

To Reproduce

Same example as for #120 but with modified shown below.

Expected behavior

Debugger stops at 1, 3 and 5.

Screenshots

Capture 2021-03-25 08-25-06

Capture 2021-03-25 08-28-37

Desktop (please complete the following information):

  • OS: Windows 10
  • Version: 2.0.0 beta 4
  • SAMD core 1.8.11

Additional context

  • Modified LocalLibrary.cpp
#include "LocalLibrary.h"

// Code
void blinkLED(uint8_t pin, uint8_t times, uint16_t ms, bool level)
{
    for (uint8_t i = 0; i < times * 2; i++)
    {
        digitalWrite(pin, (level ^(i%2)) ? HIGH : LOW);
        delay(ms >> 1);
    }
}
@rei-vilo rei-vilo changed the title Conditional breakpoint Conditional breakpoint only stops the first time Mar 25, 2021
@ubidefeo
Copy link

ubidefeo commented Apr 6, 2021

@rei-vilo
I have just tested this and it is working for me
I use an uint8_t and only break on counter % 2 == 0

@cmaglie cmaglie removed the type: bug label Sep 16, 2021
@rsora rsora added the type: imperfection Perceived defect in any part of project label Sep 22, 2021
@per1234 per1234 added the topic: debugger Related to the integrated debugger label Sep 30, 2021
@per1234 per1234 added the topic: code Related to content of the project itself label Oct 25, 2021
@per1234
Copy link
Contributor

per1234 commented Oct 27, 2021

@rei-vilo are you still having this issue with the latest nightly build of the Arduino IDE?

If so, please try to distill it down to a more minimal example. It's not clear to me whether the bug is dependent on the exact conditions produced by the fairly complex set up you provided to demonstrate #120, or whether you just happened to reuse that sketch by chance here and you would have had the same problem with even a conditional breakpoint in a minimal sketch.

@per1234 per1234 added the status: waiting for information More information must be provided before work can proceed label Oct 27, 2021
@rei-vilo
Copy link
Author

rei-vilo commented Oct 27, 2021

The same example with a local library and two breakpoints, but without the condition on the library breakpoints, stops at the two breakpoints.

However, stopping the debugging session fails with message kill failed for -4671Error: kill ESRCH.

Launching a new debugging sessions adds a second thread.

Capture d’écran de 2021-10-27 21-54-44

@per1234
Copy link
Contributor

per1234 commented Oct 28, 2021

Thanks for your quick response!

but without the condition on the library breakpoints, stops at the two breakpoints.

What about with the condition? Does the problem still occur for you with the conditional breakpoint while using the nightly build?

Is the bug dependent on the conditional breakpoint being in a "local library", or does it also occur if you put a conditional breakpoint in a simple single file sketch?

However, stopping the debugging session fails with message kill failed for -4671Error: kill ESRCH.

This is a known bug (#527) introduced by the new version of the Theia IDE framework updated to (#489). before the 2.0.0-beta.12 release. Work is in progress now on a fix: #578 (will be in the next nightly build).

@rei-vilo
Copy link
Author

The conditional breakpoint (line 10) in the main sketch is ignored.

Capture d’écran de 2021-10-28 11-10-41

@per1234 per1234 removed the status: waiting for information More information must be provided before work can proceed label Oct 28, 2021
@kittaakos kittaakos self-assigned this Nov 25, 2022
@per1234
Copy link
Contributor

per1234 commented Dec 2, 2022

Closing as fixed by #1706

After quite some deciphering of this unnecessarily complex report, I finally determined that it is the same as #412

@per1234 per1234 closed this as completed Dec 2, 2022
@per1234 per1234 assigned per1234 and unassigned kittaakos Dec 2, 2022
@per1234 per1234 added the conclusion: resolved Issue was resolved label Dec 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself topic: debugger Related to the integrated debugger type: imperfection Perceived defect in any part of project
Projects
None yet
Development

No branches or pull requests

6 participants