We are recently trying to find a tool providing the ability for concurrency issue detection. For this topic, generally, I believe in 3 steps: 1. CPR (capacity, performance, redundancy) testing, 2. Static code analysis, 3. Dynamic code analysis. CPR testing is the same thing for each product before delivery; Coverity/Klocwork (not free!) would be the ones for SCA; Insure++/Bulleye could be the ones standing for DCA. However, for DCA requesting concurrency specific and free, Valgrind would be our first choice. From this post, we will try to go thru some details about Valgrind and then focus on some key detection like concurrency. May it help.
# Download source code http://valgrind.org/downloads/current.html # Unzip the pkg bunzip valgrind-3.7.0.tar.bz2 tar -xvf valgrind-3.7.0.tar # Build, install and test ./configure make make install valgrind ls -l [root@localhost valgrindTest]# ldd /usr/local/bin/valgrind linux-gate.so.1 => (0x00e3b000) libc.so.6 => /lib/libc.so.6 (0x00606000) /lib/ld-linux.so.2 (0x005e7000) [root@localhost valgrindTest]# # Or rpm installation for Linux http://rpmfind.net/linux/rpm2html/search.php?query=valgrind # GUIs http://valgrind.org/downloads/guis.html
# Check and find the the useful tools http://valgrind.org/docs/manual/manual-intro.html 1. Memcheck is a memory error detector. It helps you make your programs, particularly those written in C and C++, more correct. 2. Cachegrind is a cache and branch-prediction profiler. It helps you make your programs run faster. 3. Callgrind is a call-graph generating cache profiler. It has some overlap with Cachegrind, but also gathers some information that Cachegrind does not. 4. Helgrind is a thread error detector. It helps you make your multi-threaded programs more correct. 5. DRD is also a thread error detector. It is similar to Helgrind but uses different analysis techniques and so may find different problems. 6. Massif is a heap profiler. It helps you make your programs use less memory. 7. DHAT is a different kind of heap profiler. It helps you understand issues of block lifetimes, block utilisation, and layout inefficiencies. 8. SGcheck is an experimental tool that can detect overruns of stack and global arrays. Its functionality is complementary to that of Memcheck: SGcheck fi nds problems that Memcheck can't, and vice versa.. 9. BBV is an experimental SimPoint basic block vector generator. It is useful to people doing computer architecture research and development. 10. Lackey is an example tool that illustrates some instrumentation basics. 11. Nulgrind is the minimal Valgrind tool that does no analysis or instrumentation, and is only useful for testing purposes.
# Quick start using Memcheck http://valgrind.org/docs/manual/quick-start.html [root@localhost valgrindTest]# cat memcheckTry.c /* Code from Valgrind Manual */ #include <stdlib.h> void f(void) { int* x = malloc(10 * sizeof(int)); x[10] = 0; // problem 1: heap block overrun } // problem 2: memory leak -- x not freed int main(void) { f(); return 0; }
[root@localhost valgrindTest]# gcc -Wall -g -o memcheckTry memcheckTry.c [root@localhost valgrindTest]# valgrind --leak-check=yes ./memcheckTry ==16907== Memcheck, a memory error detector ==16907== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==16907== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==16907== Command: ./memcheckTry ==16907== ==16907== Invalid write of size 4 ==16907== at 0x80483BF: f (memcheckTry.c:6) ==16907== by 0x80483DC: main (memcheckTry.c:11) ==16907== Address 0x4017050 is 0 bytes after a block of size 40 alloc'd ==16907== at 0x400705E: malloc (vg_replace_malloc.c:263) ==16907== by 0x80483B5: f (memcheckTry.c:5) ==16907== by 0x80483DC: main (memcheckTry.c:11) ==16907== ==16907== ==16907== HEAP SUMMARY: ==16907== in use at exit: 40 bytes in 1 blocks ==16907== total heap usage: 1 allocs, 0 frees, 40 bytes allocated ==16907== ==16907== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==16907== at 0x400705E: malloc (vg_replace_malloc.c:263) ==16907== by 0x80483B5: f (memcheckTry.c:5) ==16907== by 0x80483DC: main (memcheckTry.c:11) ==16907== ==16907== LEAK SUMMARY: ==16907== definitely lost: 40 bytes in 1 blocks ==16907== indirectly lost: 0 bytes in 0 blocks ==16907== possibly lost: 0 bytes in 0 blocks ==16907== still reachable: 0 bytes in 0 blocks ==16907== suppressed: 0 bytes in 0 blocks ==16907== ==16907== For counts of detected and suppressed errors, rerun with: -v ==16907== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 8) [root@localhost valgrindTest]#
# General compiling options -g -fno-inline (C++) -Wall NOTE: Turn off '-Ox' or only go with '-O' # Logging options --log-file=<filename> # XML report options (for GUI's consuming) --xml=yes --xml-file=<filename> # Memory leak detection --tool=memcheck (default)
Another very good post focusing on concurrency issue detection especially for Java code:
http://sqrg.science.uoit.ca/blog/?p=32