On Sunday 20 February 2011 22:12:32 Harry Van Haaren wrote: gdb is probably not the right tool for this. valgrinds helgrind is much better suited. It also doesn't hurt to run one app in callgrind and memcheck every once in a while... Have fun, Arnold

Hi Harry, On Sun, 20 Feb 2011, Harry Van Haaren wrote: In addition to the excellent suggestions from other folks... here's another approach. In Hydrogen/Composite, there is a central, critical audio lock.[3] For this lock, we set up a system for the central audio lock that would "log" the line of code that last locked the mutex. See [1] and [2]. Whenever you deadlock, you can look at this->d->__locker to see the file and line number where the mutex was last locked. This solution was suggested to us by Krzysztof Foltman, and once saved me a ton of time. Thanks, Krzysztof! The important parts are: /** * Convenience macro for locking the Engine. */ #ifndef RIGHT_HERE #define RIGHT_HERE __FILE__, __LINE__, __PRETTY_FUNCTION__ #endif And: class Engine : public EngineInterface { public: //... /////////////////////////////////////// // THE BIG LOCK /////////////////////////////////////// /* Mutex locking and unlocking * * Easy usage: Use the RIGHT_HERE macro like this... * engine->lock( RIGHT_HERE ); * * More complex usage: The parameters file and function * need to be pointers to null-terminated strings that are * persistent for the entire session. This does *not* * include the return value of std::string::c_str(), or * QString::toLocal8Bit().data(). * * Notes: The order of the parameters match GCC's * implementation of the assert() macros. */ void lock( const char* file, unsigned int line, const char* function ); bool try_lock( const char* file, unsigned int line, const char* function ); void unlock(); //... } And: void Engine::lock( const char* file, unsigned int line, const char* function ) { d->__engine_mutex.lock(); d->__locker.file = file; d->__locker.line = line; d->__locker.function = function; } bool Engine::try_lock( const char* file, unsigned int line, const char* function ) { bool locked = d->__engine_mutex.tryLock(); if ( ! locked ) { // Lock not obtained return false; } d->__locker.file = file; d->__locker.line = line; d->__locker.function = function; return true; } void Engine::unlock() { // Leave "d->__locker" dirty. d->__engine_mutex.unlock(); } -gabriel [1] http://gitorious.com/composite/composite/blobs/master/src/Tritium/Tritium/E… [2] http://gitorious.com/composite/composite/blobs/master/src/Tritium/src/Engin…

Hey, I've been using gdb, linux and mt programming for a good year or two now in a professional setting and I have following advice: 1) Get a good logging framework. We use log4cxx but I think someone is working on boost logging too. For some things you just need to be able to follow logging 2) Use valgrind often! It is usually 100% correct when it points to problems in your code but might be incorrect when pointing out problems in libs. 3) Get a good testing framework like google gtest... which you then run under valgrind... 4) Configure your system to dump core. We have tried hellgrind and found the output difficult to interpret and giving too much false positives -- but on the other hand they might be disasters waiting too happen. Greetz, Immanuel On Tue, Mar 8, 2011 at 1:24 PM, Harry Van Haaren <harryhaaren(a)gmail.com>wrote;wrote: