I have an executable built in Windows. I want to pass that .exe to an output file built by Cygwin (DOS version). It is going well up to a point, after which it is showing the following error related to Cygwin dll files (ACL check) .
Program received signal SIGSEGV, Segmentation fault.
0x6108829e in cygwin1!aclcheck () from /usr/bin/cygwin1.dll
(gdb)
Why am I getting this error and where should I look?
Check your code. Since you're already using gdb, bt full shall be your friend. You're possibly passing bad parameters such as invalid pointers to some system call.
It's likely it's not aclcheck where the segfault itself occurs. Cygwin DLLs are normally not shipped with debugging symbols built in. gdb works backwards from the instruction pointer and takes the previous symbol seen. In non-debug builds there are only symbols of exported functions.
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 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'm a C++ newbie (up to 2.4a on www.learncpp.com) and I'm having trouble debugging in codeblocks. The terminal that opens up when I start debugging says "warning: GDB: Failed to set controlling terminal: Operation not permitted
" and whenever I try to do something, an error appears in the bottom right saying that it couldn't open some file called fileops.c
Here's an image:
GDB is the GNU Debugger. Rest assured,
GDB is not broken.
The pesky warning: GDB: Failed to set controlling terminal: Operation not permitted
has appeared forever in Code::Blocks when you start debugging, due to the way
in which C::B invokes GDB. It is harmless and you can ignore it.
The GDB message fileops.c: No such file or directory appears because
you trying to step into a function that is defined in fileops.c, which
is a source file of the GNU C Library. You cannot step into such functions
because the source code of the GNU C Library that is linked with
your program is not available to GDB.
In general, the source code of any system library that your program is
linked with will not be available to the debugger and similar messages will
appear if you try to step into functions defined in those libraries.
You have to step over those functions and almost always you can do so with a good
will, because the bugs you are looking for are not there. They are in your source
code, which is available to the debugger, and plodding down through all
of the library calls, even if you could, would likely keep you debugging into
old age.
In short, there is nothing the matter. Just step over the functions that you
didn't write.
I am doing some OSX kernel debugging with lldb and KDK.
When the kernel crash,I want to view the zones,and search the zones.
So I use:
(lldb) command script import lldb.macosx.heap
(lldb) cstr_refs CSTRING
This command is always working in Ring3 debugging, but when at kernel debugging, lldb give me an error:
error: error: use of undeclared identifier 'malloc_get_all_zones'
error: 1 errors parsing expression
The script heap.py is unusable in kernel?
How to search the kernel zones at this situation？
Someone more familiar with kernel issues can maybe tell you how to get the information you want out of the kernel. I can answer the part about "heap.py". It is only meant to be used when debugging userland programs. It relies on details of the userland malloc implementation, and it relies on being able to call functions in the debugee which is not currently possible when debugging the kernel.
Note, if you get the KDK so you have the dSYM for the mach kernel, it defines a bunch of commands that poke around in the kernel's data structures. It may be one of them will tell you what you want to know. Remember to run the lldb command:
(lldb) settings set target.load-script-from-symbol-file true
in order to allow lldb to read in the Python from the dSYM that defines all these macros. Then running the lldb help command will show you all the kernel-specific commands.
Background
I am working with an ARM device using a custom-built toolchain (based on Yocto with gcc 4.7 and gdb 7.5) and make use of remote gdb debugging with Eclipse CDT as debugger frontend. Recently I had the issue that I could not debug a particular executable on the remote target due to this error (reported by the gdbserver on the target) that occurred immediately when the host gdb connected to the target:
error while loading shared libraries: unexpected PLT reloc type 0xf0
I could finally track down the issue to mismatching binaries of the dynamic linker library /lib/ld-2.16.so on the target and on the host, where, by calling set sysroot in gdb, I used a locally stored root directory of the target that is generated along with the toolchain.
Keeping the local file in sync with the remote file works, but I could also just omit setting the sysroot in order to debug at least the executable itself. This leads me to the following
Question
How does the usage of a wrong ld.so binary on the debugging host influence the execution of the application within gdbserver on the target? I would rather expect that I get just wrong debug information on the host as the executable runs without problems on the target (within gdbserver) if I have no ld.so present at all on the host. But as the behavior is different, it seems that there is some feedback from the host to the target when the file is available.
How does the usage of a wrong ld.so binary on the debugging host influence the execution of the application within gdbserver on the target?
Good question.
One possible explanation: in order to properly keep track of e.g. loaded shared libraries on the target, GDB sets a number of internal breakpoints (these are visible in maintenance info breakpoints output -- they have negative breakpoint number).
When you don't supply a local file at all, GDB has no idea where to set these breakpoints, and so it doesn't (you can't e.g. debug library initializers without them).
When you supply an incorrect local file, GDB does set the breakpoint ... in the wrong place (by overwriting what GDB thinks is an instruction, but what in reality is a PLT relocation). When the loader then encounters this overwritten relocation, it complains.