UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2012-02-29 08:13 PM

useless79
Member
Registered: 2011-10-10
Posts: 30

advance gdb commands usage

Hi,

Please post your buggy C code(s) where following advanced
gdb commands were proved useful to detect the issue. 

x/nfu <address>
disassemble
info signals
info threads
show listsize
handle <signal> <options>
set listsize <count>
$register
thread <thread#>

It will help up to know use of these gdb
commands in realistic scenario.


Thanks..

Offline

#2 2012-03-01 12:50 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,230

Re: advance gdb commands usage

I actually don't use gdb much at all. If I do, it's usually just to get a backtrace
to see where it crashed, though Valgrind works better for more complicated
cases. Once I know the location in the code, I just look at the code until I
fully understand what went wrong and then I fix the source of the problem.

For everything else, like logical bugs, I just sprinkle the code with printf()s, or
I review the code once more. For me debugging is mostly thinking of possible
causes of the strange behaviour and then test them one by one.

That said, I have used the thread, print, disassemble and breakpoint commands,
but more out of curiosity than for any debugging purposes.

Offline

#3 2012-03-01 06:01 AM

useless79
Member
Registered: 2011-10-10
Posts: 30

Re: advance gdb commands usage

Even after working these many years in C under Unix environment
I do not understand where at all these commands are required.



thanks............

Offline

#4 2012-03-01 01:55 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,826
Website

Re: advance gdb commands usage

Yeah, I pesonally loathe interactive debuggers and never use them...  They just don't fit with my work process...  Like i3839 said, the only useful feature they have to me is providing a backtrace after a seg-fault...  And, for that, I'd rather get it some other way...  (For all work software I'm usually dealing with, we have a system-wide library function that handles SIGSEGV and relatives, and then uses glibc's wonderful backtrace() and backtrace_symbols_fd() functions to dump out a trace right at crash time...  But, valgrind is also often very useful in finding the true source of problems...)  But, for difficult to track bugs, you still can't beat strategically placed debugging printf()'s, IMHO...

Offline

#5 2012-03-01 08:20 PM

useless79
Member
Registered: 2011-10-10
Posts: 30

Re: advance gdb commands usage

yes you are right Rob. printf is the best tool for debugging.
But it becomes difficult to get the root cause when code flow is
not sequential and acts based on the asynchronous signals
and there handlers. Moreover if the problem is in processes
interfaces then issue becomes more difficult to detect.


thanks..........

Offline

#6 2012-03-02 01:34 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,230

Re: advance gdb commands usage

The problem of debugging asynchronous code is that it's often timing dependent,
and the moment you run it in a debugger (especially with single-stepping). the
timing is totally different, so you get different behaviour.

Code that crashes is usually easy to debug, because it has a clear failure point.
And that bit can be found with a backtrace. After that, it usually just takes
code reviewing and a lot of thinking to find the source. If it's weird memory
corruption, then Valgrind is great. The only tricky crashes to debug are ones
that are rare, and those you can't debug interactively anyway.

But debugging an asynch running (multithreaded) process, which is buggy but
doesn't crash, interactively with gdb looks like a nightmare. It seems easier
to figure out what goes wrong some other way. With gdb you get too much
information and all of it, whether it's relevant or not. Or you have to guess
where it might go wrong and poke at that bit, but then you can as well put
a printf there. And good luck debugging race conditions with gdb, I wouldn't
know how to do that.

I pretty much always put a printf in non SIGCHLD signal handlers anyway
because they aren't performance critical and always cause unexpected behaviour.

Offline

#7 2012-03-02 02:08 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,826
Website

Re: advance gdb commands usage

I pretty much always put a printf in non SIGCHLD signal handlers anyway
because they aren't performance critical and always cause unexpected behaviour.

I'm sure you already know, but just to put it out there: it's a good idea to avoid stdio calls inside signal handlers...  If you happen to jump into the handler while you were already inside a stdio call, trying to make another call from the same thread is likely to lead to very bad behavior...  Best to stick to raw write() and such instead...  But, it is one of those situations where 99.9% of the time, using printf() and friends will be perfectly fine; but, that one time the signal arrives at just the wrong moment, you'll be sorry...

Offline

#8 2012-03-02 11:58 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,230

Re: advance gdb commands usage

It should work on stderr, which is unbuffered, right?
I know I should probably use puts or even write, but
I'm a bit lazy and count on the compiler to detect it
can replace the printf with a puts. ;-)

Offline

#9 2012-03-03 06:22 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,826
Website

Re: advance gdb commands usage

I'm not sure if it's just the buffering that's the issue or not...  I know there's some issues with locking and such deep in the guts of stdio...  I've actually seen it cause a problem before in a SIGSEGV handler, where the seg-fault was generated inside a stdio call, and then the handler tried to use fprintf() or something, and it just deadlocked and hung the process...

puts()/fputs() also goes through stdio...  But, yeah, hopefully a good optimizing compiler will replace a simple enough fprintf()/fputs() to stderr with a plain write() call...

There's also fputs_unlocked() and all the other *_unlocked() stdio calls, which probably would be much safer to use from a signal handler...

Offline

Board footer

Powered by FluxBB