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.
Related
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 implemented the program that uses mmap() system call, but Segmentation Fault occurs during process runtime.
So, I ran this program with gdb, but when I did it, it worked well without segment fault.
I wonder if it is possible that running with gdb can affect segment fault.
Could you tell me about it?
if it is possible that running with gdb can affect segment fault.
One possibility: GDB disables address randomization (so as to make reproducing the bug easier). You can re-enable it with:
(gdb) set disable-randomization off
GDB may also affect timing of threads, but you didn't mention threads, so that's less likely.
You are probably invoking Undefined Behavior somewhere in your code that is breaking C or C++ rules. Try to run the program under Valgrind. It should give you more information if this is the case.
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.
I have been debugging in GDB (C code). The issue is if I run my application and if it crashes, the control comes back to main()(app restarts). Hence will have no idea where it crashed. So I spend a lot of time stepping through each function.
I would like to know if there is anyway a log can be enabled which will generate the last line of execution before crash. This is just my assumption, if there is any other simpler way of doing this please let me know, this would save a great deal of time for me!
Also if the gdb generates a log where would the path be?
Thanks in advance.
This question is a little unclear to me, but I'll take a stab:
If you have GDB attached to the crashing process when it crashes, a crash should stop the program and put you back at the (gdb) prompt. If you then type bt, you should see the stack.
If you do NOT have GDB attached, then this answer to a related question might help. (In short, maybe you want the system to create a core dump when the program crashes. A core dump is just a file that contains a lot of information about the crashed process. You can use GDB with the core dump to see the stack.)
If you don't know, post what you see on the screen when this happens, and we'll guess.
In any case, the program definitely should not start over at main(). It seems worthwhile to track down why this happens and precisely what's going on. Does control really jump to main in the same process, as opposed to another process somehow being automatically started?
Run your program in gdb mode.
$ gdb ./myProgram
Set break point to expected location.
$ break functionName
Or set break point to particular line number.
$ break 15
Start the execution
$ r
Step into or step out the execution by 's' or 'n'
$ s
once the program crash, do 'bt' for backtrace.
$ bt
you can go up and down in your trace by 'up' & 'down' command
$ up
Can also take alternate way. Debug program with “core” as the core dump file.
$ gdb executableFilename core
$ bt
Good Morning everyone
I'm currently facing a segfault at random on a little piece of software, however, It appears only when not started with an attached debugger (due to a possible memory error, where values are initialized in a safe interval when started with a debugger).
Is it possible to attach an debugger only in case of an segfault, just-in-time, like, for example attaching Visual Studio to a process when unhanded exceptions happen in Windows?
I am working on Ubuntu, 32 bit.
thanks in advance
Out of the box, Ubuntu limits the core file size to "none". Changing it with ulimit -c unlimited will allow your errant program to dump core like it should and then GDB will be happy to allow post-mortem analysis of the fault.