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.
I am using commons-daemon-1.0.15 and Ubuntu 14.04.
I followed the tutorial here: http://www.neilson.co.za/creating-a-java-daemon-system-service-for-debian-using-apache-commons-jsvc/
In my program I generate a runtime-exception which is caught by the catch-all handler. This handler exits the program with code code 1.
However, jsvc does not restart the program.
Is jsvc supposed to restart a program which exits with a non-zero code.
Thanks!
I found the solution,
My catch-all handler should exit with code 123. That causes jsvc to restart the jvm
I keep getting the SIGABRT error with my app. I've tried re-downloading my entire developer profile certificates and provisioning certs etc and still no change. I've also played with changing architectures. The activity log for my project when it crashes is below - any one know what's causing it?
[CODE]GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16 06:56:50 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys001
sharedlibrary apply-load-rules all
target remote-mobile /tmp/.XcodeGDBRemote-1268-71
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
[Switching to process 7171 thread 0x1c03]
[Switching to process 7171 thread 0x1c03]
Couldn't register sh.heather.reactionfree with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.(gdb) [/CODE]
I've had this problem a few times. I'm not sure but it seems to occur for me when I continually build and run without stopping the previous build in the simulator. (I try to always press the stop button now)
Things to try
Sometimes this is fixed by just quitting the simulator and Xcode.
Sometimes I've had to do a full system restart.
So they may get you back on your feet quickly but I would also enjoy hearing the reason/fix from someone who knows more.
you must be having memory management issues,. just clean build it and then press analyze for any issues/ leaks and dead memory management problems... once all are cleared then your program functions as per your coding.
We are randomly seeing this error during long executions of our system. The error is caught by our alarm system, and we successfully retry, and continue running the system. The only hits we found on Google seem to mention corrupt installations. We do not think this is the case here, since our systems are running, get the error, and can continue running.
Register the .dll file again from a command window by using the below command:
regsvr32 C:\WINDOWS\system32\msvbvm60.dll
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.