I am using c in eclipse to write a program. I need to use GDB to debug it step by step. However on a longjmp command (when i try to save the context of a stack) GDB crashes inside eclipse (because there is a breakpoint there?) Is there any way around this? I have scoured the internets for the past six hours and cannot seem to be able to find a solution. Here is the line of code where it is crashing
if(setjmp(p->jbContext) == 0)
longjmp(context_buf,1);
I would be very very grateful to anyone that can help.
Thanks!
EDIT: After further searching I found this webpage but have no clue as to how to use it.
http://www.delorie.com/gnu/docs/gdb/gdb_271.html
Assistance would be appreciated!
If it is really gdb which crashes, you could consider (after reporting the bug to them) install a newer version of it. Latest GDB is version 7.3.1 -you can compile it from its source code if needed. If you are brave and the bug persists with the latest version, try to find the bug and propose a patch.
My experience with gdb crashes (which are rare) is that getting and building the newest version helps a lot. Many Linux distributions don't ship a very recent GDB.
Of course, you might need to upgrade your GCC compiler also: the debugging information that is generated has also improved.
Related
Newbie coder. Mainly work with use a text editor (sublime/atom) with the command line.Usually code in C but will be moving on to Java and Databases soon.
I want to start use Valgrind and GDB (the former i understand is good practice for detecting memory issues). However i understand that these are not available as standard tools on Mac's and alternatives such as LLDB exist.
Could someone suggest the alternative (if that is possible) e.g. LLDB for GDB; Explaining why this is appropriate?
Supplementary literature would be appreciated (I find online tutorials for GDB are widely available...but cant say the same for LLDB (from a dumbed down perspective of a beginner such as myself)).
valgrind is a great tool, but it's good to have a variety of such tools on hand, so...
Xcode ships with a tool called ASAN (address sanitizer) which does many of the same memory analysis techniques that valgrind does. That's easiest to use if you build your project with Xcode. Then you just edit the Run scheme (Product->Scheme->Edit Scheme, then choose Run) choose the Diagnostics tab and turn on ASAN. If you run in Xcode, when an error is triggered, it will show you the relevant stacks (the original alloc plus the two free's for a double free, etc...)
If you are building outside Xcode, here's a link to the ASAN documentation:
http://clang.llvm.org/docs/AddressSanitizer.html
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 am using gcc 4.4.3 on ubuntu 10.4 32bit machine.
i use 'gdb' to debug my code. Since few days i am seeing that whenever i debug code gdb steps into the c library functions used in the code also(like printf,fgets etc). This shows a long list of calls from one function to other.see the attached screen shot.
Previously gdb was working fine just stepping over my own code.
Maybe i am being novice !! But it is sometimes really irritating when gdb shows me numerous lines which i am not interested in the present context.
If someone can guide me as in how to turn off/on this feature and what can be cause of it being switched on on its own(i don't remember doing anything).
Many thanks.
i used to do that previously also but then it never went into any of the lib functions
You (or someone) have installed libc6-dbg package. Before that, GDB couldn't step into libc functions, because they didn't have any debug info. Now they do, and it can.
Either get out of the habit of typing step when you want next, or un-install libc6-dbg.
I have learned C and I would like to start to improve open source software. I would like to hack away one irritating bug in GTK+. To see the bug I need to use Gedit.
How can I download the sources of GTK+ and gedit and compile both of them so that I can see where the bug is? And I have never used any debugger in Linux so is there somewhere a tutorial for that?
You can get information about downloading and compiling of gedit here:
http://projects.gnome.org/gedit/developers.html
My Debugger of choice is GDB:
http://www.gnu.org/software/gdb/
GDB is a console application that may be hard to handle for a beginner. Try an IDE like Eclipse that provides a GUI to GDB.
Almost all Linux debuggers are front-ends for or adaptations of the gdb debugger. You should therefore learn how to use this first, preferably by starting on
small programs of your own construction, not giant FOSS codebases. The gdb manual,
available from here is actually a pretty good tutorial.
The information on building and installing GTK+ should be here:
http://www.gtk.org/development.html
The sources should be here:
http://www.gtk.org/download-linux.html
You can check out gdb:
http://www.gnu.org/software/gdb/ That's a pretty standard linux debugger. I would spend time with it on something simple first, or get an IDE that uses it. Learning gdb can be worth the time though.
gdb is a dinosaur which should long since have been made extinct. Debugging is one area where (gasp!) Windows beats Unix. Having got that off my chest, I advise you to start with the Data Display Debugger (DDD) graphical front end to gdb. Yes, the GUI is quaint, but you will be far more productive, quicker, than if you start with gdb.
Also don't overlook valgrind for finding and diagnosing memory errors. The KDE project actually mandates use of valgrind; I'm not sure about Gnome.
It is possible that you won't see the bug if you download the latest gedit and gtk+ sources. It might be fixed in the latest sources or the latest sources might be different enough to not trigger your bug.
What Linux distribution are you running?
First of all I'd suggest consulting your distribution's bug database to see if someone has filed a similar bug. If you don't find anything, I'd suggest using your distribution's tools to obtain the source that corresponds to the binary that you have installed on your sytem (e.g. apt-get source libgtk-2.0 on Debian or Ubuntu).
Also, your distribution might also make a debug package available (e.g. libgtk2.0-0-dbg on Debian) which will let you run a debugger on the binary that you already have without requiring the source. While this is no substitute for having the sources, it can be useful for running valgrind or making sense out of a core file.
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.