Restart not updating code location in editor

[microwavesafe]

When I click on restart (or pause then restart), the debugging session does not jump to the init functions. The Debug console outputs "Resetting target", but the code stays in the old location and the call stack window doesn't change.

If I then click the step over button, it jumps to the correct location, so I'm convinced the reset is actually taking place, it's just the editor / call stack that isn't updated.

[Marus]

Thanks for the report - I had this problem before and I thought I was completely fixed, but perhaps it is still happening in some cases.

What is your OS and VS Code versions? Also, what GDB server are you using?

[microwavesafe]

OS Ubuntu Gnome 16.04, VS Code 1.22.2, Cortex Debug plugin, says 0.1.19 in the extensions left hand pane, but the changelog only goes to 0.1.18.

GDB server is JLinkGDBServer 6.22g (I did update to 6.32, but downgraded after I had some problems that in hindsight were probably related to Eclipse).

[Marus]

Thanks for the details; will try to have a look soon.

[microwavesafe]

Also the runToMain option works well after starting the debug session, but when pressing restart, then step, I am stepped into the init functions, not main.

[Marus]

Yes, at the moment the runToMain functionality hasn't been implemented in the restart request. The reason for that is with many core/debugger combinations have a very limited number of breakpoints they can use (often as little as 2) - so when restarting I can't guarantee that I can actually set the temporary breakpoint. I need to add some functionality so that it can remove the breakpoints for the runToMain step and then re-create them after it breaks at main; until I have a chance to do that I can't implement the runToMain in a reliable fashion in the restart situation.

[nxyd]

I found that appending a command 'target-download' can make it jump to the init function correctly when click on restart.
like this:

[chetferry]

Can you provide more details about your restartCommands? any chance you would be willing to show which file it goes into? Thanks.

[nxyd]

@Marus Can you test if it is working using my solution see above. It works fine on my side.

[Marus]

Yeah - I think that may be an issue introduced with newer versions of VS Code - need to see if I can find a new way to force VSCode to refresh.

…

On Wed, May 2, 2018 at 6:41 AM microwavesafe ***@***.***> wrote: When I click on restart (or pause then restart), the debugging session does not jump to the init functions. The Debug console outputs "Resetting target", but the code stays in the old location and the call stack window doesn't change. If I then click the step over button, it jumps to the correct location, so I'm convinced the reset is actually taking place, it's just the editor / call stack that isn't updated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeirdHUqEkHqmz2Kufx-t0geC8QhFvwks5tuX9YgaJpZM4TvJxo> .

-- Marcel Ball <maball@gmail.com>

----------------------------------------------- The purpose of writing is to inflate weak ideas, obscure pure reasoning, and inhibit clarity. With a little practice, writing can be an intimidating and impenetrable fog! - Calvin

[nxyd]

It is better if you can find the root cause. This is only a workaround for me to use.

[nxyd]

@Marus Have a plan to fix this?

[rk-exxec]

Is there a fix for this issue in the making?

[haneefdm]

Btw, if you are using an RTOS, this is a common problem with OpenOCD and JLink especially if you have runToMain disabled. GDB never gets an updated stack

[rk-exxec]

Alright. Though I am not using a RTOS nor JLink. I have the Tiva Launchpad tm4c123gxl and connect with Stellaris ICDI JTAG/SWD interface.

[haneefdm]

@rk-exxec Sorry to hear that. Does a single step fix the issue? We only report what GDB reports

[rk-exxec]

yes, when I step then the position is shown correctly again.

[haneefdm]

There is no workaround for this. Not with gdb and most of the gdb-servers. With OpenOCD, there is a workaround that is used in VSCode (changes in master, not yet released).

Note that this only happens if you enable breakAfterReset which is no longer the default, so you don't see this problem anymore.

The final workaround (for servers other than OpenOCD) is to do a single step to get the real stack trace. I have not found any gdb-trick to fix this. So, I am closing this issue