|
From: Phil S. <pp...@us...> - 2009-06-05 14:38:46
|
I am trying to build and use valgrind 4.3.1 on a Cell BE-based system and I am having a few problems. I built and configured with no options other than --prefix. It configures/makes/installs without problems, but I am having the following issues. Any tips and suggestions about what to do would be appreciated. Has anybody successfully tried this? 1) The shared library backtraces only say (within .....). If I switch back to the 3.3 version installed on the system using the same executable and libraries, I get meaningful backtrace entries 2) I get errors through the dl libraries -- Maybe I just need to manually suppress them? ==30294== 20 bytes in 1 blocks are still reachable in loss record 1 of 3 ==30294== at 0x17A33DC: calloc (vg_replace_malloc.c:397) ==30294== by 0xFCF1497: _dlerror_run (in /lib/libdl-2.8.so) ==30294== by 0xFCF0D63: dlopen@@GLIBC_2.1 (in /lib/libdl-2.8.so) ==30294== by 0x16E723B: (within /home/vguser/libXXX.so.1.0) ==30294== by 0x16E7963: (within /home/vguser/libXXX.so.1.0) ==30294== by 0x16D7087: (within /home/vguser/libXXX.so.1.0) ==30294== by 0x1801BFB: main (SC08.c:64) ==30294== ==30294== ==30294== 28 bytes in 1 blocks are still reachable in loss record 2 of 3 ==30294== at 0x17A5D74: malloc (vg_replace_malloc.c:207) ==30294== by 0xFFBD32F: _dl_map_object_deps (in /lib/ld-2.8.so) ==30294== by 0xFFC3F07: dl_open_worker (in /lib/ld-2.8.so) ==30294== by 0xFFBE9EF: _dl_catch_error (in /lib/ld-2.8.so) ==30294== by 0xFFC36D3: _dl_open (in /lib/ld-2.8.so) ==30294== by 0xFF4281F: do_dlopen (in /lib/libc-2.8.so) ==30294== by 0xFFBE9EF: _dl_catch_error (in /lib/ld-2.8.so) ==30294== by 0xFF42A6F: __libc_dlopen_mode (in /lib/libc-2.8.so) ==30294== by 0xFCC2CDB: pthread_cancel_init (in /lib/libpthread-2.8.so) ==30294== by 0xFCC2E4B: _Unwind_ForcedUnwind (in /lib/libpthread-2.8.so) ==30294== by 0xFCBFAEB: __pthread_unwind (in /lib/libpthread-2.8.so) ==30294== by 0xFCB72BF: pthread_exit (in /lib/libpthread-2.8.so) ==30294== ==30294== ==30294== 84 bytes in 1 blocks are still reachable in loss record 3 of 3 ==30294== at 0x17A5D74: malloc (vg_replace_malloc.c:207) ==30294== by 0xFFC3B5B: add_to_global (in /lib/ld-2.8.so) ==30294== by 0xFFC41DB: dl_open_worker (in /lib/ld-2.8.so) ==30294== by 0xFFBE9EF: _dl_catch_error (in /lib/ld-2.8.so) ==30294== by 0xFFC36D3: _dl_open (in /lib/ld-2.8.so) ==30294== by 0xFCF0E4F: dlopen_doit (in /lib/libdl-2.8.so) ==30294== by 0xFFBE9EF: _dl_catch_error (in /lib/ld-2.8.so) ==30294== by 0xFCF1413: _dlerror_run (in /lib/libdl-2.8.so) ==30294== by 0xFCF0D63: dlopen@@GLIBC_2.1 (in /lib/libdl-2.8.so) ==30294== by 0x16E723B: (within /home/vguser/libXXX.so.1.0) ==30294== by 0x16E7963: (within /home/vguser/libXXX.so.1.0) ==30294== by 0x16D7087: (within /home/vguser/libXXX.so.1.0) 3) many valgrind regresssion test failures (== 383 tests, 42 stderr failures, 11 stdout failures, 0 post failures ==) There isn't anything real obvious. For example memcheck/tests/leak-cycle shows memcheck/tests/leak-cycle.stderr.diff 5c5 < 24 (8 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 18 --- > 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 18 12c12 < 24 (8 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 18 --- > 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 17 of 18 19c19 < 48 (8 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 17 of 18 --- > 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 18 25,31d24 < < 48 (8 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 18 < at 0x........: malloc (vg_replace_malloc.c:...) < by 0x........: mk (leak-cycle.c:11) < by 0x........: mkcycle (leak-cycle.c:22) < by 0x........: main (leak-cycle.c:59) < 33,34c26,27 < definitely lost: 32 bytes in 4 blocks. < indirectly lost: 112 bytes in 14 blocks. --- > definitely lost: 48 bytes in 3 blocks. > indirectly lost: 144 bytes in 9 blocks. 36c29 < still reachable: 0 bytes in 0 blocks. --- > still reachable: 96 bytes in 6 blocks. 37a31,32 > Reachable blocks (those to which a pointer was found) are not shown. > To see them, rerun with: --leak-check=full --show-reachable=yes 40,41c35,36 < malloc/free: in use at exit: 144 bytes in 18 blocks. < malloc/free: 18 allocs, 0 frees, 144 bytes allocated. --- > malloc/free: in use at exit: 288 bytes in 18 blocks. > malloc/free: 18 allocs, 0 frees, 288 bytes allocated. |
|
From: Julian S. <js...@ac...> - 2009-06-05 14:50:01
|
> 1) The shared library backtraces only say (within .....). If I switch back > to the 3.3 version installed on the system using the same executable and > libraries, I get meaningful backtrace entries > > 2) I get errors through the dl libraries -- Maybe I just need to manually > suppress them? No. (2) is a side effect of (1), or to be more precise, (2) and (1) have the same root cause. See https://bugs.kde.org/show_bug.cgi?id=190820. J |
|
From: Bart V. A. <bar...@gm...> - 2009-06-05 14:53:48
|
On Fri, Jun 5, 2009 at 4:38 PM, Phil Sanders<pp...@us...> wrote: > I am trying to build and use valgrind 4.3.1 on a Cell BE-based system and I > am having a few problems. I built and configured with no options other than > --prefix. It configures/makes/installs without problems, but I am having > the following issues. Any tips and suggestions about what to do would be > appreciated. Has anybody successfully tried this? > > 1) The shared library backtraces only say (within .....). If I switch back > to the 3.3 version installed on the system using the same executable and > libraries, I get meaningful backtrace entries It might be a good idea to add yourself to the CC list of http://bugs.kde.org/show_bug.cgi?id=190820. > 2) I get errors through the dl libraries -- Maybe I just need to manually > suppress them? Suppressions for the dl libraries should be added to Valgrind's default suppression list IMHO. > 3) many valgrind regresssion test failures (== 383 tests, 42 stderr > failures, 11 stdout failures, 0 post failures ==) Not all regression tests do already pass on PPC -- more work is needed in this area. The output you got is close to the results of the latest nightly build on a Cell BE system -- see also http://sourceforge.net/mailarchive/forum.php?thread_name=20090605111553.GA17495%40cell-user.cell.buzz&forum_name=valgrind-developers. Bart. |