I am not sure if this is because lldb does not use the new shared libs. What happened is
1) I used a lldb in emacs to debug a code
2) updated the shared libs the code needs
3) re-run the program debugged by lldb.
The code run and stopped at some random location. The problem was resolved if I killed the debug session in emacs, and opened a new one. I never have the same issue with gdb.
This also happens when switching between optimized and debug code. The steps are like
1) lldb an optimized program
2) build the program in debug mode
3) rerun the program in lldb. lldb does not use the new debug code.
Related
I'm using XDebug with Visual Studio Code on Windows 10 to debug PHP.
The debugger works but from time to time it's getting stuck (hits the breakpoint but doesn't respond to step in, step over commands).
I tried switching to XDebug nts version (Not Thread Safe) but it doesn't help. Restarting the web server (Apache) doesn't resolve it either. Sometimes computer restart helps but not always...
Any solution or workaround? (Even a command line that frees this deadlock)
Having out of context debug expressions in the watch window causing the debugger to get stuck.You should clear the watch window from expressions.I guess the evaluation of out of context expressions make the debugger to get stuck.
After upgrading to Python 3.6, Eclipse debug mode stopped working properly. It renders an error like this:
The strangest thing is that this issue does not raise in 100% of cases. Sometimes it goes away. And then again arises. I am lost trying to figure out why.
Although it happens when you're running the PyDev debugger, the debugger is probably only exercising some path in your code which has a bug and is usually not exercised (and thus leads to such an error).
In this case, attach a c/c++ debugger to the program to find the culprit (you can use the attach to after that error is hit)... On Windows you can use Visual C++ and on Linux GDB.
-- as a note, the issue is probably on some c/c++ library you're using (but given the info, it's really hard to pinpoint anything).
I'm trying to get debugging of go programs working in eclipse Luna with goclipse v0.11.0 on OS-X 10.9.5. I am using GNU gdb (GDB) 7.9.1 from brew, and go1.4.2.
I successfully installed and code-signed gdb using instructions here:
http://ntraft.com/installing-gdb-on-os-x-mavericks/
I am building my go program with -gcflags "-N -l" and I can successfully debug it at the command line, including setting breakpoints at go functions and stepping through them with the gdb command line, with source appearing as it should.
However, in goclipse I cannot set a breakpoint at all, because the 'toggle breakpoint' item on the menu is greyed out, and the 'Breakpoint Types' list says 'none available'.
If I select 'Stop on Startup at' 'main', then I can step through assembler, which is unhelpful, but proves gdb is being used.
If I keep the above option set, wait until the program hits the main breakpoint, and type (at the gdb console within eclipse) break main.foo, then cont, then a breakpoint is set in the right place, and I can step through things in the Eclipse IDE. Thus it appears the only issue is setting the breakpoints in the IDE.
The go program concerned is a single file and it works under command line gdb, and I have deleted the binary and started afresh, so this is not a 'need a rebuild' issue.
Related question: How to debug Go programs using GoClipse? however the two answers there are 'disable Stop on Startup' (which makes no difference here), and ensuring -gcflags "-N -l" is given (which makes no difference).
Screenshot:
Any ideas?
I'm having an issue when attempting to analyze variables in the Eclipse IDE, while in debug mode. At a breakpoint, I'll try to expand a data structure, in the Eclipse variables window, however, the member doesn't display and the program running on the board seems to crash. Once this happens, the only way to reconnect over the jtag is to reboot the board and restart Eclipse.
Without knowing for certain, it seems to be an error with memory allocation in the IDE, but I don't know. Is this a common problem when debugging over jtag? Where might I begin looking to resolve the issue?
I'm trying to use gdb with emacs. The library that I'm trying to debug is loaded by a process and can't be run directly. Hence I attach to the process by using the attach command inside gdb. Attaching to a process and setting breakpoints works fine when I use gdb from a shell, but when I use gdb in emacs (by pressing M-x gdb or M-x gud-gdb), it can't set breakpoints. It shows me an error which says "Can't access memory at 0x7efb04". I'm using emacs 23.1.1.
Here is a breakdown of the process I follow:
Press M-x gdb or M-x gud-gdb to launch gdb inside emacs.
Enter the name of the executable built with debugging symbols.
Type "attach [PID]" to attach gdb to a running process.
Set a breakpoint by typing: filename:line number.
The last step gives me an error which says "Can't access memory at 0x7efb04".
Any ideas why this is happening?
EDIT : I get the same error when using DDD (UI for GDB). So I guess it's not an emacs specific issue.
Have you compiled with debug-information? Do you have some code which shows the problem?
Does this happen in other IDEs also?
I figured it out. The problem is with step 2. Entering the name of the executable built with debugging symbol causes the problem. Instead, just launching GDB and attaching to process works fine. I'm not sure if this is the expected behavior.
In DDD, the executable with debugging symbols has to be opened first before we can attach to process. I don't know how to get around that in DDD.