Skip to content

[ARM] Need to run debugging session twice when debugging multithreaded application #1075

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.

Sign up for GitHub

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

Jump to bottom
Open
UR3IQO opened this issue Sep 27, 2017 · 4 comments
Open

[ARM] Need to run debugging session twice when debugging multithreaded application #1075

UR3IQO opened this issue Sep 27, 2017 · 4 comments
Labels
debugger embedded

Comments

@UR3IQO
Copy link

UR3IQO commented Sep 27, 2017 •
edited
Loading

Here is:
cpptools v0.13.0
VSCode 1.16.1
Windows 8

I use VS Code to develop application for the ARM Cortem-Mx MCUs. When starting debugger with multithreaded application (with OpenOCD threads support) I need to run debugger session twice - first time VS Code drops debugging session. Standalone gdb-OpenOCD session runs flawlessly.

That is not a big problem, cause debugger functions properly after the second start, but it looks like something is broken.

Here is the debug log of the VSCode for the first debugger start:
first.txt

And here is for the second one:
second.txt

Note: when application starts there is no OS running yet, so OpenOCD reports there is a fake thread (thread id 1). This thread terminates on OS start and new real threads created.

The problem may be related to #978 issue.
@pieandcakes pieandcakes changed the title Need to run debugging session twice when debugging multithreaded application [ARM] Need to run debugging session twice when debugging multithreaded application Sep 27, 2017
@pieandcakes
Copy link
Contributor

pieandcakes commented Sep 27, 2017 •
edited
Loading

@sov1178 Looking at the logs, in the first one there are two things:

  • Thread 1 seems to exit early so we get the following error, I don't think that matters though.

->=thread-exited,id="1",group-id="i1"
1: (1038) ->=thread-created,id="2",group-id="i1"
1: (1038) ->=thread-created,id="3",group-id="i1"
1: (1038) ->=thread-created,id="4",group-id="i1"
1: (1038) ->=thread-created,id="5",group-id="i1"
1: (1039) ->=thread-created,id="6",group-id="i1"
1: (1039) ->=thread-created,id="7",group-id="i1"
1: (1039) ->=thread-created,id="8",group-id="i1"

and

E output: {"category":"stderr","output":"ERROR: Unable to start debugging. Failed to find thread 1 for break event\r\n","data":null,"type":"output"}
ERROR: Unable to start debugging. Failed to find thread 1 for break event

  • At the bottom of the first log, it looks like the thread-group that all the threads are part of has exited leaving no running threads so we request logout:

1: (1293) ->=thread-group-exited,id="i1"
1: (1296) <-logout

I would expect that if other threads are running, the thread-group that they belong to, in this instance i1 doesn't exit while its running.

I don't know if this is an issue in our code or an issue in the arm gdb version.

@UR3IQO
Copy link
Author

UR3IQO commented Sep 28, 2017

Thread 1 seems to exit early so we get the following error

@pieandcakes Thread 1 will always exit as soon as OS starts - it is not the real thread. OpenOCD makes fake thread to tell gdb that something is running before the OS starts. So it is OK. I do not know what caused thread-group exit message. I will see OpenOCD logs and write more.

I don't know if this is an issue in our code or an issue in the arm gdb version.

If I run gdb+OpenOCD with the same project/settings but without VSCode everything works finely, so it looks like it is related to VSCode.

@cooperbaker
Copy link

Bump.

Exact same problem. Any solution?

@cvonk
Copy link

cvonk commented May 10, 2019

I see the same on ESP32, but it disappears when I disable FreeRTOS support in the board configuration file. Sorry, don't have an ARM board at hand.

*) in my case "set ESP32_RTOS none"

asialasr pushed a commit to asialasr/vscode-cpptools that referenced this issue Mar 12, 2021
@WardenGnaw
Convert MIDebugEngine to use SDK csproj (microsoft#1075)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode
1462085 
* Convert MIDebugEngine to use SDK csproj

This PR converts all the C# projects to use the new styled sdk projects.

https://docs.microsoft.com/en-us/dotnet/core/project-sdk/overview

1. Cleaned up bin output
   - Removed xunit binaries
   - Removed reference to System.Text.Json and System.Memory
   - Set 'Private: False' to referenced packages
2. Cleaned up Reference tags to System that were not needed
3. Removed unused methods that used dynamic also removed CSharp
   Reference
4. Cleaned up labels and organized some XML

Need to use VSSDK 16.8.3038 or later for this to run in Windows GitHub
CodeSpaces
@vindicatorr vindicatorr mentioned this issue Nov 12, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
debugger embedded
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@robotdad @cvonk @pieandcakes @cooperbaker @UR3IQO