|
From: Greg C. <gre...@ya...> - 2012-06-10 23:42:21
|
Hello, I've been looking for the best way to valgrind a SystemC binary. Tried several valgrind versions including 3.6.0, 3.7.0, and 3.8.0 from SVN checked out yesterday. Running on SUSE64 SLES10SP3-3 x86-64_linux26. But the early messages are warnings on client switching stacks.. ==11609== Warning: client switching stacks? SP change: 0x7fefefa38 --> 0x10c7e5238 ==11609== to suppress, use: --max-stackframe=29838321664 or greater ==11609== Warning: client switching stacks? SP change: 0x10c7e4908 --> 0xf2d16398 ==11609== to suppress, use: --max-stackframe=430761328 or greater ==11609== Warning: client switching stacks? SP change: 0xf2d161c8 --> 0x10c7d51f8 ==11609== to suppress, use: --max-stackframe=430698544 or greater ==11609== further instances of this message will not be shown. ==11609== Use of uninitialised value of size 8 ==11609== at 0x13018711: ??? (in /path/systemc-2.2.0.icc.rpath/lib-linux64/debug/libsystemc.so) ==11609== by 0xAAAAAAAAAAAAAAA9: ??? ==11609== by 0xBBBBBBBBBBBBBBBA: ??? ==11609== by 0xBBBBBBBBBBBBBBBA: ??? ==11609== Uninitialised value was created by a stack allocation ==11609== at 0x130186F9: ??? (in /path/systemc-2.2.0.icc.rpath/lib-linux64/debug/libsystemc.so) After adding --max-stackframe=29838321664 (and patching valgrind to support 128GB processes) it gets hungrier... ==2195== Warning: client switching stacks? SP change: 0x1ffefefa38 --> 0x79fd32b8 ==2195== to suppress, use: --max-stackframe=135375472512 or greater Now it's asking for ~126GB --max-stackframe? If I don't set this flag valgrind issues lots of false positives around uninit values... ==2195== Use of uninitialised value of size 8 ==2195== at 0x13018741: ??? (in /path/systemc-2.2.0.icc.rpath/lib-linux64/debug/libsystemc.so) ==2195== by 0xAAAAAAAAAAAAAAA9: ??? ==2195== by 0xBBBBBBBBBBBBBBBA: ??? ==2195== by 0xBBBBBBBBBBBBBBBA: ??? ==2195== Uninitialised value was created by a stack allocation ==2195== at 0x13018729: ??? (in /path/systemc-2.2.0.icc.rpath/lib-linux64/debug/libsystemc.so) The 0xAA.. and 0xBB.. come from using the malloc-fill and free-fill flags.. Here are the args I am using --error-limit=no --track-origins=yes --log-file=valgrind.log --leak-check=full --show-reachable=yes --malloc-fill=AA --free-fill=BB --gen-suppressions=yes --max-stackframe=29838321664 Any suggestions? |