|Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications|
by J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team
Paperback (6"x9"), 164 pages
RRP £12.95 ($19.95)
9.7 A To-Do List for Helgrind
The following is a list of loose ends which should be tidied up some time.
- Track which mutexes are associated with which condition variables, and emit a warning if this becomes inconsistent.
- For lock order errors, print the complete lock cycle, rather than only doing for size-2 cycles as at present.
- Possibly a client request to forcibly transfer ownership of memory from one thread to another. Requires further consideration.
- Add a new client request that marks an address range as being “shared-modified with empty lockset” (the error state), and describe how to use it.
- Document races caused by gcc's thread-unsafe code generation for speculative stores. (2)
- Don't update the lock-order graph, and don't check for errors, when a “try”-style lock operation happens (e.g. pthread_mutex_trylock). Such calls do not add any real restrictions to the locking order, since they can always fail to acquire the lock, resulting in the caller going off and doing Plan B (presumably it will have a Plan B). Doing such checks could generate false lock-order errors and confuse users.
- Performance can be very poor. Slowdowns on the order of 100:1 are not unusual. There is quite some scope for performance improvements, though.
|ISBN 0954612051||Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications||See the print edition|