| Last updated February 22, 2006 |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| |
| Data-race detection algorithm |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| - pthread rwlock state tracking and support. |
| - Fix Fedora 7 / Fedora 8 pth_cond_race regression test failure. |
| - Implement segment merging, such that the number of segments per thread |
| remains limited even when there is no synchronization between threads. |
| - Find out why a race is reported on std::string::string(std::string const&) |
| (stc test case 16). |
| - Eliminate the upper bounds on the number of mutexes, condition variables, |
| semaphores and barriers by converting arrays into OSet's. |
| - Add a regression test for pthread_mutex_timedlock(). |
| - Performance testing and tuning. |
| - testing on PPC and AIX (current implementation is only tested on X86 and |
| AMD64). |
| - Change s_threadinfo[] from an array into an OSet or VgHashTable, in order to |
| make ThreadId <> DrdThreadId <> pthread_t conversions faster. |
| - [AMD64] Find out why removing 'write(1, "", 0)' in drd_intercepts.c triggers |
| a crash on AMD64. Is this a drd or a VEX bug ? |
| |
| Testing |
| ~~~~~~~ |
| - testing with more complex multithreaded test programs. |
| - test drd's performance with the SPLASH-2 software, e.g. fft |
| (http://www-flash.stanford.edu/apps/SPLASH/). |
| - Add helgrind's unit tests to drd's unit test set by adding soft links |
| under drd/tests to the respective helgrind unit tests. |
| |
| |
| Documentation |
| ~~~~~~~~~~~~~ |
| - Document how to use the tool. |
| - Document the code. |
| |
| |
| Known bugs |
| ~~~~~~~~~~ |
| - Gets killed by the OOM handler for realistically sized applications, |
| e.g. knode and OpenOffice. |
| - [x86_64] Reports "Allocation context: unknown" for BSS symbols on AMD64 |
| (works fine on i386). This is a bug in Valgrind's debug info reader |
| -- VG_(find_seginfo)() returns NULL for BSS symbols on x86_64. Not yet in |
| the KDE bug tracking system. |
| |
| Known performance issues: |
| - According to cachegrind, VG_(OSet_Next)() is taking up most CPU cycles. |
| Probably due to the bitmap implementation. |