When I attempt to use breakpoints, rather than stopping at the breakpoint and allowing me to step through my program, IAR will exit to the default interrupt handler file for my STM chip. More specifically, it will stop and goes to the reset handler located in my startup file for IAR debugging.
I'm using an I-Jet which is their recommended debugging tool and this hasn't happened to me before on the same project. Is this a setting I overlooked or is this buggy behavior someone else has found as well? Usually when I hit pause or put in a breakpoint it stops at that point in the file so I can watch my variables as I run through the program. IAR 8.40.2 if that helps.
#pmacfarlane was correct. I had enabled a watchdog that would prompt IAR to go to the system reset file rather than pausing on a breakpoint. Code is actually set as optimized but that has not seemed to affect these symptoms.
Related
I connected to my server via ssh on vs code. When I debug gem5, I use gdb to debug, but I have to display variables through commands like p var every time. Can I debug in vs code? Or is there any other way that I can display the value of the variable just by pointing at the variable with the mouse, just like debugging in visual studio?
I realize that gem5 is just a c++ executable program.
So I run it like a normal c++ program, but it doesn't stop at the breakpoint, it executes all.
This problem arises:
&"warning: gdb: failed to set controlling terminal: operation not permitted\n"
I tried the solutions in this video, but none of them worked.
https://www.youtube.com/watch?v=w_fpGfjAdXg&ab_channel=RoelVandePaar
I use the Code runner plugin to debug other C++ programs normally. What should I do please?
Adding the following changes to launch.json should help you set up gdb in vscode with Gem5. I found using GDB to be very useful to determine the call-chain and find errors.
"program": "${workspaceFolder}/build/X86/gem5.debug",
"args": ["--debug-break=<timestamp>", "${workspaceFolder}/<path to config file>"],
So my code had an invalid syntax, which I was trying out to see if it works and while compiling I got App threw an error during load.
Now in the command-prompt the error is listed in detail with the cursor still blinking but NOT WRITABLE. Closing, re-opening, re-navigating and restarting with electron . only seems to work.
Can't do the same for many errors I might face. So, is there a way to not let that happen? How are you guys dealing with it? Is it in anyway connected to stopping the npm server? If it helps, I'm using a Win 7 64bit OS.
Found a way, which is to terminate the batch job by hitting CTRL + C, which asks Terminate batch job (Y/N)? where choosing Y terminates and makes the command prompt writable.
I was searching for methods to terminate without confirmation and learnt it cannot be terminated without confirmation.
An error happens when updating classes and resources while in a debug session in Intellij.
Hotswap failed: [whatever] reason.
This error is produced when Intellij's Hotswap fails and the code in question is not updated by debugger.
How to solve this ? so that I don't have to stop and start the debug process again.
From what I've figured out this usually fails if the debugger is paused at some break point in the code. If you resume the program and try to update classes and resources it should work fine.
I'm using Visual Studio Professional 2013 and I'm doing some very basic windows forms application.
A month ago, I could do everything I wanted without any problem. But I started some new projects today and for absolutely no reasons, I keep getting this error message when I come to debug or compile:
Debug error BC31019 : Unable to write to output file 'path/form.exe System Error &H80070005&
It can happen simply by changing the size of a textbox or modifying the text content in a label... It's very random... And I can even do an undo (ctrl+z) and then I can debug again, but if I try again to do the thing I did that brought the error message, the same message pops again as I try to run.
After reading a little about the subject, I realized that it was because the .exe file became in read-only mode and when I try to remove it, windows wont let me.
The only thing I can do if I really want to continue, is to restart my computer every times it happens. Then I can continue just like normal as my .exe file is no longer in read-only...
I tried tor run a sfc/scannow in my command prompt to see if i had any problems with my frameworks but everything was fine.
Since, it is when i restart my pc that the bug disapears, isn't anything i can do or run somewhere to do the same thing. I need to find why the exe file goes to read-only for nothing and how to get it back to normal without having to restart my pc every time...
Please help me!
thank you
I came across the same issue and it was related to having a command line argument that VS could not find, then when i clicked stop debugging I ended up in this situation as it seemed VS kept a process running.
I could see this process in task manager but could not end it (it started with the same name as my app)
I found closing VS would release this process.
Restarting VS it would then work ok again.
there may be other ways to reproduce the issue but restarting VS seems to release the file and allow you to continue.
I set the exe properties to Read/write. No effect, but when I set app properties/settings to "Always on top" = False the issue went away and is still away.
When you're doing a usual gdb session on an executable file on the same computer, you can give the run command and it will start the program over again.
When you're running gdb on an embedded system, as with the command target localhost:3210, how do you start the program over again without quitting and restarting your gdb session?
You are looking for Multi-Process Mode for gdbserver and set remote exec-file filename
Unfortunately, I don't know of a way to restart the application and still maintain your session. A workaround is to set the PC back to the entry point of your program. You can do this by either calling:
jump function
or
set $pc=address.
If you munged the arguments to main you may need set them up again.
Edit:
There are a couple of caveats with the above method that could cause problems.
If you are in a multi-threaded program jumping to main will jump the current thread to main, all other threads remain. If the current thread held a lock...then you have some problems.
Memory leaks, if you program flow allocates some stuff during initialization then you just leaked a bunch of memory with the jump.
Open files will still remain open. If you mmap some files or an address, the call will most likely fail.
So, using jump isn't the same thing as restarting the program.
"jump _start" is the usual way.
Presumably you are running gdbserver on the embedded system.
You can ask it to restart your program instead of exiting with target extended-remote
Step-by-step procedure
Remote:
# pwd contains cross-compiled ./myexec
gdbserver --multi :1234
Local:
# pwd also contains the same cross-compiled ./myexec
gdb -ex 'target extended-remote 192.168.0.1:1234' \
-ex 'set remote exec-file ./myexec' \
--args ./myexec arg1 arg2
(gdb) r
[Inferior 1 (process 1234) exited normally]
(gdb) r
[Inferior 1 (process 1235) exited normally]
(gdb) monitor exit
Tested in Ubuntu 14.04.
It is also possible to pass CLI arguments to the program as:
gdbserver --multi :1234 ./myexec arg1 arg2
and the ./myexec part removes the need for set remote exec-file ./myexec, but this has the following annoyances:
undocumented: https://sourceware.org/bugzilla/show_bug.cgi?id=21981
does not show on show args and does not persist across restarts: https://sourceware.org/bugzilla/show_bug.cgi?id=21980
Pass environment variables and change working directory without restart: How to modify the environment variables and working directory of gdbserver --multi without restarting it?
If you are running regular gdb you can type 'run' shortcut 'r' and gdb asks you if you wish to restart the program
For me the method described in 21.2 Sample GDB session startup works great. When I enter monitor reset halt later at the “(gdb)” prompt the target hardware is reset and I can re-start the application with c (= continue).
The load command can be omitted between the runs because there is no need to flash the program again and again.
You can use jump gdb command. For that, you can check your startup script.
My startup script has a symbol.
.section .text.Reset_Handler
.weak Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
ldr r0, =_estack
mov sp, r0 /* set stack pointer */
I wanted to jump to start. That's why I used:
jump Reset_Handler
On EFM32 Happy Gecko none of the suggestions would work for me, so here is what I have learned from the documentation on integrating GDB into the Eclipse environment.
(gdb) mon reset 0
(gdb) continue
(gdb) continue
This puts me in the state that I would have expected when hitting reset from the IDE.