I have a C application which is compiled to run on redhat linux architecture, which runs just fine during normal execution. However, as soon as I start trying to debug it using GDB, it crashes: Child terminated with signal = 0xb (SIGSEGV).
The thing is that there are some caveats here - it is a linux application, but I am debugging remotely using gdbserver from a windows machine. I followed the steps in this article: https://www.linux.com/news/remote-cross-target-debugging-gdb-and-gdbserver, which basically state that I need to compile a cross-platform version of GDB that will run on Windows but can debug Linux applications. I have done this. The application is running inside a docker container on my local machine at which point I have run gdbserver on the container. I have created the cross-platform GDB executable and I am running it, connecting to the gdbserver on the docker container.
It can attach the breakpoints meaning it is finding the symbols just fine, yet as soon as the application starts doing anything, it crashes due to segfault.
The thing here is that I know it's somehow related to the cross-platform-ness of the GDB executable. If I run the regular GDB from the Windows Subsystem for Linux and connect to the gdbserver using that, it works just fine, yet the cross-platform compiled GDB causes segfaults. So, does anyone have any clues about what I might be able to do about this?
The whole point of doing this is to be able to debug using an IDE (preferably VSCode) which is why I need to use the cross-platform GDB executable and can't just use the Windows Subsystem for Linux GDB.
Any help would be greatly appreciated.
Related
I need to debug some C code which is running on a VM (which has a different architecture from host machine) from Eclipse debugger (which is on my host machine). Basically I need to monitor a variable to see which thread or function modifies it.
On VM I'm running 32-bit Debian 8, and on the host I have 64-bit Ubuntu 16.04. I compiled my code on both machine using gcc.
I tried configuring Eclipse remote debugger and I can connect to the VM, but I can't see any code inside Eclipse debugger (I can only see hex values which seem to be function's memory location), preventing me from using it.
on the VM, run dbg or ddd
The above are both debuggers
I need to debug a C program that includes posix threads, socket programming (udp client, server). I use ubuntu 12.04 and as IDE/SDK, Qt Creator 2.4.1 and Netbeans IDE 7.1.2. I know they use gdb for debugging.
When I start to debug my program, the program stops running after 5 min or so and neither Qt Creator or Netbeans output any error or warning, although I use debugging feature and my program suppose to listen for a UDP port.
I use printf for all line of my code, and I can see that my program works as it suppose to and listen the UDP port and waits. I can not figure the problem out why it stops without any reason and since IDEs that I am using do not show any debug error, warning, I can not think any reason.
I wonder if anyone can suggest me a debug program that monitors all/some variables and threads during the run time. Thank you.
An old, but reliable tool is ddd, which is basically the gdb GUI wrapper. Although, I usually do debugging directly with Emacs, ddd is the tool that you'll be able to run on almost all *nix platforms.
gdb isn't too comfortable but always available.
To do runtime analysis of different types, especially checking memory access, Valgrind (see here for docs) might be the tool of choice.
Update: I'm referring to *IX systems. For Windows gbd also works in the cygwin enviroment. Nativly there is VC Express, which is free and includes IDE and debugger.
I'm not quite sure what debugger is used for your kind of application. The only debugger I know about on Linux is gdb. It along with printf statements is all I need.
gdb is simple, though not "too comfortable" as #alk said, but seems to be ubiquitous.
There is also Eclipse, and that's quite a nice development and debugging platform, too.
I want a debugger to debug my OS. At many places i am not being able to figure out what is wrong. So is there any debugger which can debug operating systems? can i do it with gdb?
You will need to use a solution which emulates another computer on your computer - essentially, a virtual machine. The most obvious ones which come to mind instantly are VirtualBox and VMware, but those weren't designed with debugging the machine and/or the OS.
What you're looking for is either Bochs or QEMU. Both (as far as I remember) can be integrated with gdb in order to set breakpoints and analyze the execution of your code. You might also want to read this OSdev.org article.
I primarily use Bochs for testing my OS projects. It includes a helpful debugger (bochsdbg).
I'm trying to debug a simple cross-platform commandline program (a C parser, itself written in C) and running into something strange.
On Windows, when I run it on a small dataset (the source code of glib) it completes successfully, and when I run it on a large dataset (the source code of the Linux kernel) it exits with an out of memory error. I'm not sure whether the latter is a bug in my code or just a consequence of not just having optimized the memory consumption yet, so I've been trying to run it on Linux so I can get some feedback from valgrind.
On Linux (Ubuntu 11.04 x64 in VirtualBox), when I run my program on a small dataset it completes successfully, and when I run it on a large dataset Linux locks up hard enough I have to reset the entire virtual box (mouse pointer still moves but other than that it's completely unresponsive; Windows task manager says the virtual box is using one hundred percent of a CPU core but not allocating memory).
I wouldn't have expected a bug in my code to crash Linux unless I was writing something like a device driver, and when I try simple test cases that allocate too much memory, go into an infinite loop or both, Linux can handle them just fine. What kind of bug should I be looking for, or what am I missing?
On Linux (Ubuntu 11.04 x64 in VirtualBox)
Probably you haven't reserved enough memory to your virtual machine.
This is most likely an infinite loop (easily done in a parser), which could easily take up 100% cpu or 100% ram.
Attach a debugger!
e.g. gdb
http://www.gnu.org/s/gdb/
gdb comes with gcc on Ubuntu etc...
Here's a how-to: http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
EDIT: just saw you already tried gdb. So, try running strace on it, it might give you a hint.
Further to that, try adding log messages to see how far the program gets (primitive, but it'll work eventually!)
HI, i am recently in a project in linux written in C.
This app has several processes and they share a block of shared memory...When the app run for about several hrs, a process collapsed without any footprints so it's very diffficult to know what the problem was or where i can start to review the codes....
well, it could be memory overflown or pointer malused...but i dunno exactly...
Do you have any tools or any methods to detect the problems...
It will very appreciated if it get resolved. thanx for your advice...
Before you start the program, enable core dumps:
ulimit -c unlimited
(and make sure the working directory of the process is writeable by the process)
After the process crashes, it should leave behind a core file, which you can then examine with gdb:
gdb /some/bin/executable core
Alternatively, you can run the process under gdb when you start it - gdb will wake up when the process crashes.
You could also run gdb in gdb-many-windows if you are running emacs. which give you better debugging options that lets you examine things like the stack, etc. This is much like Visual Studio IDE.
Here is a useful link
http://emacs-fu.blogspot.com/2009/02/fancy-debugging-with-gdb.html
Valgrind is where you need to go next. Chances are that you have a memory misuse problem which is benign -- until it isn't. Run the programs under valgrind and see what it says.
I agree with bmargulies -- Valgrind is absolutely the best tool out there to automatically detect incorrect memory usage. Almost all Linux distributions should have it, so just emerge valgrind or apt-get install valgrind or whatever your distro uses.
However, Valgrind is hardly the least cryptic thing in existence, and it usually only helps you tell where the program eventually ended up accessing memory incorrectly -- if you stored an incorrect array index in a variable and then accessed it later, then you will still have to figure that out. Especially when paired with a powerful debugger like GDB, however (the backtrace or bt command is your friend), Valgrind is an incredibly useful tool.
Just remember to compile with the -g flag (if you are using GCC, at least), or Valgrind and GDB will not be able to tell you where in the source the memory abuse occurred.