Skip to content

Thread reporting behavior inconsistent #1934

@kikakeule

Description

@kikakeule

The "threads disable" command is behaving inconsistently.

When using "threads disable" before the first resume, the command is ignored. This is in contrary to the command being described to be "manual control" for the "not perfect" logic of enabling reporting only after the first resume.

Expected: "monitor threads disable" disables thread reporting until "monitor threads enable"

But instead, since gdbserver.first_run_after_reset_or_flash is True, the manual action is ignored:

if self.first_run_after_reset_or_flash:
self.first_run_after_reset_or_flash = False
if self.thread_provider is not None:
self.thread_provider.read_from_target = True

I'm suggesting to change this behavior. Its unintuitiv that the manual action is silently ignored.

For now I solved this using a user script. But obviously, this is brittle, using internal, undocumented attributes and may become incompatible in the future. So this is not a final solution. I'm still leaving this here for anybody encountering the same issue:

@command(help="Prevent pyOCD from auto-enabling RTOS reads on the next first resume")
def clear_first_run(core: int = 0):
    gdbserver = session.gdbservers[core]
    gdbserver.first_run_after_reset_or_flash = False
    print(f"core {core}: first_run_after_reset_or_flash cleared")

and instead of continue, call

monitor threads disable
monitor clear_first_run 0
continue

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions