the problem is not to debug c, php, python, etc in emacs, but debug emacs itself.
i have confronted with a segmentation fault error when i try to enter gdb mode in emacs using
Mx gdb Enter
now i have build emacs with debug info, and have load it using "gdb emacs" command.
l command shows the source code of emacs,
now my problem is how to debug emacs? where i should set that breakpoint?
howto find the origin of segmentation fault using gdb?
the following is a screenshot about what i have did now, so any suggestions how i should debug emacs? and where to set break points?
http://i1271.photobucket.com/albums/jj624/bigmeowOoO/emacs_where-i-should-set-breakpoint-when-debug-emacs.jpg
howto find the origin of segmentation fault using gdb?
Don't set any breakpoints (yet). Simply use run command. That will start emacs running (under GDB control).
In that emacs, do M-x gdb. emacs will crash (if you are lucky), and you'll get (gdb) prompt right at the crash point.
From there, use gdb to examine the state of emacs at crash point. Figure out which variables have wrong values, etc. Then figure out where these variables are set, set the breakpoints there, and repeat (just as you would if you were debugging any other program -- there is nothing special about emacs being your buggy program).
P.S. Please don't post pictures where a simple text cut/paste will convey exactly the same information.
Related
I'm trying to use LLDB to debug a program on OSX and control-C is not working to stop the program. It seems to be in an infinite loop and I want to see where it is; hence I can't just use breakpoints. This used to work for me -- I used to be able to control-C to send SIGINT and LLDB respected it and stopped the program on this computer with this same toolchain. I see the ^C in the terminal but it's being ignored. I also tried to send the signal to the lldb process in two other ways:
via the Activity Monitor's send signal to process feature
via pkill -SIGINT lldb
However, that didn't work either. control-z DOES work to stop lldb, on the other hand but that's not what I need (which is to be able to inspect program state).
I tried this both with the built-in Terminal app as well as iTerm2 - but I'm seeing the same behavior on both.
Version info
lldb --version
lldb-1000.11.38.2
Swift-4.2
I think this is the version of lldb installed with XCode. It's possible that an upgraded XCode (which I don't use directly) broke this.
Update: I'll add that variable names are not auto-completing for me in lldb either -- I'm pretty sure this also used to work. For example, if I type p and then start typing a variable name, it doesn't tab-complete. I'm adding this update in case it may be related.
See comment above -- it seems that this was a bug with lldb version 1000.11.38.2 when using a command script that contained run in it. Upgrading and/or not using a command script with run allows the program to be interrupted.
I am trying to write a simple OS, I already wrote a bootloader but now I want to debug it, so I switched from using VirtualBox to QEMU because I saw it had better debugging.
The problem is that after I added the -s parameter to QEMU command and successfully connected via GDB, it says that the symbol table isn't loaded and that I should use the "file" command.
The only difference from what I did to what I saw people on the Internet do, is that they started GDB with gdb vmlinux, but I can't do that because I am not debugging a Linux kernel... so I figured that the issue is that I didn't start GDB with an executable, but using the "file" command on my OS image, and the compiled and linked .out file, tells me it's a "DOS/MBR boot sector", so I can't start GDB with either of them (I tried to do that anyways, but GDB failed).
Help would be appreciated.
EDIT: also, I did assemble the bootloader with the -g and --gstabs+ options.
gdb would like a file so that it can give you symbolic debugging information. For that you will need to give it a file in a format with debug info which corresponds to where your OS ends up in RAM. The "DOS/MBR boot sector" file is a disk image (the BIOS will load part of this into RAM for you, and it will then presumably finish loading code itself).
But gdb will also entirely happily let you do assembly-level debugging; you can just ignore the warning about not having a symbol table, and use the single step instruction, disassemble-from-pc and similar commands:
"disas $pc,+32" disassembles 32 bytes from the current PC
the display command prints after execution stops, so "disp /3i $pc" will print the next 3 instructions every time gdb gets control
"stepi" and "nexti" do single-instruction step/next ("step" and "next" are source-line stepping and require debug info)
I am trying to debug a fortran program within Emacs using GDB. My compiler is intel fortran 2017.4. The problem is with a particular subroutine which inverts a matrix. The program runs without a problem when the size of the matrix is "small" i.e. 100x100. When I increase the size of the matrix to, for example 600x600, I get the following message: "Thread 3 received signal SIGSEGV, Segmentation fault."
Now, if I try to debug the program launching GDB from the terminal, everything works fine. I strongly prefer to debug the program from within Emacs since it would save me a lot of time. Any ideas about how can I fix this issue?
I already try to increase the stack size to the max (which is 65532 for MAC) and all the arrays are allocated on the heap.
Thanks for your help,
Now, if I try to debug the program launching GDB from the terminal, everything works fine.
It appears that your program does not crash when run from GDB (whether GDB is invoked from within Emacs or from a terminal), in which case your references to Emacs are superfluous.
Some of the reasons why a program may not crash under GDB are listed here.
I am developing an ncurses program. So running this in Xcode fails because the Console is just for stdout/stderr, but it is not a full terminal emulation (and hence can’t run ncurses programs).
To easily use the debugger, I would like to tweak the Scheme that the “Run” feature starts the application in Terminal.app or iTerm.app instead.
Does anyone know how to achieve this? My first attempts to change the Executable in the “Run” section of the scheme editor to use Terminal.app and use arguments were not successful (but then again, I am not familiar with possible arguments for Terminal.app).
Update: Thanks for pointing to How to run command-line application from the terminal? - this is indeed almost what I am after. The problem is that at least on OS X 10.11, SIP (System Integrity Protection) requires to turn off the "Debug Executable" option (besides, I don't want to debug Terminal.app, but rather my application).
So the remaining question is if it is possible to let the "Run" also start the debugger the debug the built executable (i.e. without manually attaching the debugger after the executable was started).
I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx