I run
C:\Users\io\simics-projects\my-simics-project-1>simics.bat targets\qsp-x86\firststeps.simics
I then run "run" and let the system proceed all the way to the clear linux shell prompt. I then run "stop" to pause the simulation. But I get an error of "No current debug object". I would think a simple stack trace would simply follow the %rbp frame pointers backwards on the stack and display what's there. Why isn't it?
simics> run
Autologin as "simics" was done on "board.mb.sb.com[0] - serial console".
running> stop
simics> bt
No current debug object
(I also just noticed the same happens when I just try "step-out". Which again, I would think would simply step through instructions until after it hits a "ret"...)
I think the debugger is not enabled. To do so, the command is
enable-debugger
Related
In gdb I can type watch &variable, then continue and gdb will break whenever something writes to that address.
I am using vscode to debug and want to do the same thing (This is different from the watch window, which will only show variable values after a breakpoint has been hit). Is it possible?
I can manually add a breakpoint by clicking the '+' and enter &variable but it never becomes active and says the module has yet to be loaded. I've tried manually entering -exec watch &variable in the debugger console window, but after continuing execution with the play button it hangs (vscode thinks the program is running again but it's not).
There are some github issues for this but they're closed without reason:
https://github.com/microsoft/vscode/issues/55931
https://github.com/microsoft/vscode/issues/47117
https://github.com/microsoft/vscode-debugadapter-node/issues/38
I had luck watching on an address. For example, if my target variable was at address 0xb79b90, I would execute -exec watch *0xb79b90 in the gdb terminal. Then I'd double check it was added as a hardware watchpoint with -exec info watch.
After continuing execution, the debugger would halt with an exception once the watchpoint is hit. vscode would display the line after the value was changed. I could then continue from there if necessary.
I need to debug a running program running on windows.
It some times crashes with "memory access violation".
With windbg (usage of IDE not possible) I attached to running process (it is a requirement the program shall not stop)
The command line is
windbg -g -p <pid>
The problem is that I now catch all first chance exceptions but I am only interested in any second chance exception (do not care which type of exception).
How can I setup windbg to catch any second chance exception?
WinDbg will catch second chance exceptions by default, so you just need to turn off the first chance exceptions. Doing this for a single type of exception is simple:
0:000> sxd av
0:000> *** Check the setting
0:000> .shell -ci "sx" find "av"
See set all exceptions to set all exception types to second-chance only.
Since it does not seem to be an option to perform those commands at debug time, you can also try to configure a Workspace that has exception handling disabled and then reuse the workspace. For understanding the concept of Workspaces, the MSDN article Uncovering how Workspaces work was really helpful. It is a set of experiments that you should do yourself once.
With that background knowledge, attach to any process
0:000> .foreach(exc {sx}) {.catch{sxd ${exc}}}
0:000> *** perhaps some other useful workspace relevant commands here
0:000> *** e.g. .symfix seems useful
0:000> *** File / Save Workspace As ...
0:000> *** Enter a name, e.g. myworkspace
0:000> q
Restart WinDbg with the -W myworkspace command line switch. Attach to any process. Check if your setting have been applied (e.g. sx, .sympath). If everything is fine, you can start debugging.
I have a running Perl process that’s stuck, I’d like to poke inside with a debugger to see what’s wrong. I can’t restart the process. Can I attach the debugger to the running process? I know I can do gdb -p, but gdb does not help me. I’ve tried Enbugger, but failed:
$ perl -e 'while (1) {}'&
[1] 86836
$ gdb -p 86836
…
Attaching to process 86836.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ............................. done
Reading symbols for shared libraries + done
0x000000010c1694c6 in Perl_pp_stub ()
(gdb) call (void*)Perl_eval_pv("require Enbugger;Enbugger->stop;",0)
perl(86836) malloc: *** error for object 0x3: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x00007fff8269d82a in __kill ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (Perl_eval_pv) will be abandoned.
(gdb)
Am I doing it wrong? Are there other options?
P.S. If you think you could benefit from a debugger attached to a running process yourself, you can insert a debugger back door triggered by SIGUSR1:
use Enbugger::OnError 'USR1';
Then you can simply kill -USR1 pid and your process will jump into the debugger.
First, please use a DEBUGGING perl, if you want to inspect it with gdb.
Please define "stuck". Busy or non-busy waiting (high or low CPU), eating memory or not?
With while 1 it is busy waiting. I usually get busy waiting (endless cycles) on HV corruption in Perl_hfree_next_entry() since 5.15. Non-busy waiting is usually waiting on a blocking IO read.
I get the correct:
`0x00007fba15ab35c1 in Perl_runops_debug () at dump.c:2266`
`2266 } while ((PL_op = PL_op->op_ppaddr(aTHX)));`
and can inspect everything, much more than with a simple perl debugger. With a non-threaded perl you have to type less.
`(gdb) p Perl_op_dump(PL_op)`
and so on.
If you have to do with perl: Inside the pp_stub function it is not a good idea to enter the Enbugger runloop, you should be in the main runloop in dump.c. Set a breakpoint to the shown line.
"error for object 0x3" on eval sound like internal corruption in the context, so you should look at the cx and stack pointers. Probably because you started it in a bad context.
I've never used gdb, but maybe you could get something useful out of strace?
strace -f -s512 -p <PID>
http://metacpan.org/pod/App::Stacktrace
“perl-stacktrace prints Perl stack traces of Perl threads for a given Perl process. For each Perl frame, the full file name and line number are printed.”
I'm using the Scala REPL to interactively test some hash functions I'm building. I'm constantly switching between the product code (Eclipse), the browser and the Scala interpreter, doing copy/paste of values and results. In the mix I'm often doing CTRL-C on the interpreter, exiting the session and loosing all my functions.
Is there any way to let the Scala REPL either ignore CTRL-C or, even better, perform "paste" with it? I'm working on Linux.
I only know how to prevent REPL from exiting. Remapping of CTRL+C to perform copy command could be done in the same way (if there is some command that ables to change keymap w/out restarting terminal -- I don't know is there one). Anyways, to block ^C wrap your REPL invocation in .sh script like this:
#!/bin/bash
#switch off sensitivity to ^C
trap '' 2
# here goes REPL invoke
scala
#get back sensitivity to ^C
trap 2
trap command
defines and activates handlers to be run when the shell receives
signals
or other conditions.
2 is a SIGINT value (that's the signal which is triggered when you press CTRL+C)
The repl already intercepts ctrl-C, but apparently it doesn't work on linux. It does work on osx. If someone who uses linux opens a ticket with sufficient detail to indicate why not, I can fix it.
As an alternative to the native Scala REPL, you can use Ammonite, which does handle Ctrl+C:
# while(true) ()
... hangs ...
^Ctrl-C
Interrupted!
#
The traditional Scala REPL doesn't handle runaway code, and gives you no option but to kill the process, losing all your work.
Ammonite-REPL lets you interrupt the thread, stop the runaway-command and keep going.
I'm using Eclipse CDT with Zylin embedded debug (native) and arm-elf-gdb 6.6 on OS X 10.5.8.
I've got an OCD debugger connecting to a board with an ARM processor.
Eclipse is able to stop at the first breakpoint and gather variables from memory, but any subsequent breakpoints or single-steps fail. I can set breakpoints ok when using commandline gdb, but setting breakpoints at the exact same location gives me these errors in Eclipse:
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0x3f6: Unknown error: -1.
And my OCD connection dies with "Error: unexpected error -308"
I'm using the same OCD script in both cases.
The only differences I see are (1) Eclipse uses Zylin and the mi protocol to talk to gdb, and (2) my gdb script is invoked differently in this way:
When running from gdb, I use a script file that ends with these two lines:
load filename.out
symbol-file filename.out
In Eclipse, I copy the contents of this script file into "Debug Configurations | Commands" (I've tried both the "'Initialize' Commands" and "'Run' Commands" boxes. I replace the last two lines with load, and specify filename.out in the "Debug Configurations | Main | C/C++ Application" box.
I'd appreciate any suggestions about how to get Zylin+Eclipse to behave.
Thanks.
I'm using the same solution on a LPC2103.
Go to Eclipse, in Zylin Debug Configurations > Embedded Debug (Native):
Main tab: C/C++ Application = you_elf_file.elf
Debugger tab: GDB debugger = arm-elf-gdb; GDB command set = Standard; Protocol = mi2
Commands:
'Initialize' commands:
target remote localhost:3333
monitor arm7_9 dcc_downloads enable
monitor arm7_9 fast_memory_access enable
monitor arm7_9 dbgrq enable
monitor reset halt
monitor wait_halt
monitor sleep 500
load
'Run' commands:
continue
I'm using parallel port Wiggler and OpenOCD [Open On-Chip Debugger 0.4.0] with the cfgs that came with the installation:
openocd -f interface/parport.cfg -f target/lpc2103.cfg
It works most of the time for me.