Program executes too slow to debug under gdb

Program executes too slow to debug under gdb

[Paul Nolan]

In-Reply-To: <964166418.24549.ezmlm@sources.redhat.com>
Hello,

Can anyone offer some suggestions on how I can debug my application at a usable 
speed under gdb?  I`m using RedHat 6.2 on a 500mhz Dell Inspiron 7500 laptop, 
and have tried gdb 4.18 and 5.0, as well as other Linux distributions 
(several testers have reported the same problem too).  I`ve tried compiling with -

optimisation turned on, but with the same results - my app runs so slowly under 
gdb that its almost impossible to even select a menu item in less than 15 
minutes.  The only things I`m doing that might be considered the slightest bit 
unusual is calling a lot of functions, often recursively, to levels 40 or so 
deep, and using several linux threads.  If you would like an example, there is a -

.tgz archive of the app here: 
http://www.paulnolan.com/Linux/Updates/PhotogenicsB89.tgz

Thanks in advance,

Paul

Re: Program executes too slow to debug under gdb

[Mark Kettenis]

   Date: Fri, 21 Jul 2000 09:59 +0100 (BST)
   From: pnolan@cix.compulink.co.uk (Paul Nolan)

   Hello,

   Can anyone offer some suggestions on how I can debug my application
   at a usable speed under gdb?  I`m using RedHat 6.2 on a 500mhz Dell
   Inspiron 7500 laptop, and have tried gdb 4.18 and 5.0, as well as
   other Linux distributions (several testers have reported the same
   problem too).  I`ve tried compiling with optimisation turned on,
   but with the same results - my app runs so slowly under gdb that
   its almost impossible to even select a menu item in less than 15
   minutes.  The only things I`m doing that might be considered the
   slightest bit unusual is calling a lot of functions, often
   recursively, to levels 40 or so deep, and using several linux
   threads.  If you would like an example, there is a .tgz archive of
   the app here:
   http://www.paulnolan.com/Linux/Updates/PhotogenicsB89.tgz

   Thanks in advance,

Apart from the fact that I don't want to run random binaries from
unknown sources, a stripped binary of your program is of no use at all
to us.  If you want us to help, please provide the source code of a
small test program and detailed instructions on how to reproduce the
problem.

That said, the most likely reason your program runs so slowly under
GDB is because it generates a lot of signals.  This can have various
reasons, the ones that come to mind are:

* You're using a high frequency timer in your program.  You could try
  to use a virtual timer (ITIMER_VIRTUAL instead of ITIMER_REAL,
  SIGVTALRM instead of SIGALRM) instead, but there is no real solution
  for the problem in this case.  If you want to be able to debug your
  program you'll have to rewrite it such that ut doesn't depend on the
  timer :-(.

* You have a lot of lock contention (multiple threads all wanting to
  acquire a single mutex), which generates a lot of inter-thread
  communication/synchronization signals.  Lock contention is a very
  bad and you should find out why it occurs.  It almost certainly
  means that there is something wrong with your program.

Mark