Locking Issues
(→Debugging mutex issues) |
(→Debugging mutex issues) |
||
| Line 21: | Line 21: | ||
Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output#Debugging_levels|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library. | Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output#Debugging_levels|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library. | ||
| + | |||
| + | ====Special debugging options==== | ||
The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name. | The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name. | ||
| Line 26: | Line 28: | ||
'''See also''' | '''See also''' | ||
| − | *[[Mutexes and locking]] | + | * [[Starting Yate]] |
| − | *[[Debug Output]] | + | * [[Mutexes and locking]] |
| + | * [[Debug Output]] | ||
Revision as of 14:36, 19 November 2012
Countless bugs can result from improper locking resources. Yate being a multithreaded program a multitude of problems can occur from bad programming.
For developers' help this page tries to provide an overview of problems caused by improper locking and how to troubleshoot them.
Contents |
Lack of locking
A lack of proper resource locking usually leads to a race condition when the order of some operations is not guaranteed.
The effect can range from subtle (counters not properly incremented) to dramatic program crashes if one thread alter other's pointers.
Deadlocks
A deadlock situation occurs when one or more threads are trying to acquire two or more Mutexes waiting for each other to finish. Since each is trying to acquire other's lock while holding its own locked this situation never ends.
The typical symptom of a deadlock is that the program (or part of it) stop responding.
Debugging mutex issues
Debugging multithreaded programs is a difficult task since usually the problems occur infrequently. There can be millions of iterations until a detectable problem actually occurs.
Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a DebugFail message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate Thread object and not from some library.
Special debugging options
The -Dm command line option makes lock operation abort after 10 seconds with a DebugFail level message. Associated with the -Da and -C (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.
See also
