You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(29) |
2
|
|
3
|
4
(4) |
5
(1) |
6
|
7
(4) |
8
(3) |
9
|
|
10
(1) |
11
(9) |
12
(5) |
13
(3) |
14
|
15
|
16
|
|
17
|
18
|
19
(11) |
20
(5) |
21
|
22
(3) |
23
|
|
24
|
25
(3) |
26
(1) |
27
(5) |
28
(2) |
29
|
30
|
|
31
|
|
|
|
|
|
|
|
From: Robert W <rob...@gm...> - 2008-08-19 07:53:49
|
Hi, Does anyone know where I can get pre-compiled valgrind binaries for ppc32? Thanks. Regards, Rob |
|
From: chang a. <and...@gm...> - 2008-08-19 07:06:15
|
Dear Sir, I have an question for you. I built my project code to be an binary(image) and upload to our device, Wireless Router. I would like to use the Valgrind to find memory leak. How should I do that? I just know to simulate on PC with JTAG, USB or LAN when the chip set debugging function is available. Our device have LAN only without debugging function as far as I knew. How should I do simulate Valgrind with our device? Re-built our code with Valgrind source code? Thanks, Best Regards, AndrewChang. |
|
From: andrew t. <and...@ma...> - 2008-08-19 06:51:37
|
Dear Sir, I have an question for you. I built my project code to be an binary(image) and upload to our device, Wireless Router. I would like to use the Valgrind to find memory leak. How should I do that? I just know to simulate on PC with JTAG, USB or LAN when the chip set debugging function is available. Our device have LAN only without debugging function as far as I knew. How should I do simulate Valgrind with our device? Re-built our code with Valgrind source code? Thanks,Best Regards,AndrewChang. -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com |
|
From: andrew t. <and...@ma...> - 2008-08-19 06:48:20
|
Dear Sir, I have an question for you. I built my project code to be an binary(image) and upload to our device, Wireless Router. I would like to use the Valgrind to find memory leak. How should I do that? I just know to simulate on PC with JTAG, USB or LAN when the chip set debugging function is available. Our device have LAN only without debugging function as far as I knew. How should I do simulate Valgrind with our device? Re-built our code with Valgrind source code? Thanks,Best Regards,AndrewChang. -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com |
|
From: andrew t. <and...@ma...> - 2008-08-19 06:46:20
|
Dear Sir, I have an question for you. I built my project code to be an binary(image) and upload to our device, Wireless Router. I would like to use the Valgrind to find memory leak. How should I do that? I just know to simulate on PC with JTAG, USB or LAN when the chip set debugging function is available. Our device have LAN only without debugging function as far as I knew. How should I do simulate Valgrind with our device? Re-built our code with Valgrind source code? Thanks,Best Regards,AndrewChang. -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com |
|
From: Tom H. <to...@co...> - 2008-08-13 07:45:25
|
In message <20080812150738.S38I7.15874.root@mp19>
cat...@ch... wrote:
> So after reading all about ... (internet) and going thru the manual.
> valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
> I found one post about trying to test a 32 bit process on a 64 bit machine.
> which is what I am trying to do.
Sounds it didn't build 32 bit support - what did configure say when
you ran it?
> more detailes below, but my question is,
> can I run valgrind 3.3.1 on a 32 bit process on a 64 bit machine?
Yes, if it is build and installed correctly.
> I tried -valgrind --tool=memcheck --enable-only32bit ./myProgram
> valgrind --enable-only32bit --tool=memcheck ./myProgram
> and got same error.
The --enable-only32bit flag is a configure flag, not a flag to
valgrind. You shouldn't need it anyway as without that flag it
will build support for both 32 and 64 bit binaries.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-08-13 07:43:54
|
In message <1A5...@sv...>
Alasdair Ferro <Ala...@me...> wrote:
> If you are trying to run Valgrind on a 64-bit OS, but with 32-bit
> binaries you will need to have installed BOTH 64-bit and 32-bit versions
> of Valgrind.
No you won't, at least not normally. Unless you say otherwise
valgrind will build support for both 32 and 64 bit binaries when
you build it on a 64 bit box so you will only need to build it
once.
> Therefore you should find:
> <prefix>/lib/valgrind/x86-linux/memcheck - 32-bit memcheck
> <prefix>/lib/valgrind/amd64-linux/memcheck - 64-bit memcheck
Correct, but those are all created by the 64 bit build - there
is no need to do a 32 bit build as well.
> <prefix> is what ever you passed when Valgrind was compiled, but is
> often /usr/bin. My current RHEL4 box has two different RPMs - one for
> the 32-bit and one for the 64-bit. I find that generally the 32-bit one
> isn't installed on a 64-bit installation (along with lots of other
> 32-bit libraries).
I bet you don't really need the 32 bit package. Certainly the
rpms I make have both 32 and 64 bit support in them when they are
created on a 64 bit system.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Ferro, A. <Ala...@me...> - 2008-08-13 07:37:35
|
James, If you are trying to run Valgrind on a 64-bit OS, but with 32-bit binaries you will need to have installed BOTH 64-bit and 32-bit versions of Valgrind. Therefore you should find: <prefix>/lib/valgrind/x86-linux/memcheck - 32-bit memcheck <prefix>/lib/valgrind/amd64-linux/memcheck - 64-bit memcheck <prefix> is what ever you passed when Valgrind was compiled, but is often /usr/bin. My current RHEL4 box has two different RPMs - one for the 32-bit and one for the 64-bit. I find that generally the 32-bit one isn't installed on a 64-bit installation (along with lots of other 32-bit libraries). BTW, this applies to every version of Valgrind I ever used! I hope this helps, Alasdair -----Original Message----- So after reading all about ... (internet) and going thru the manual. valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory I found one post about trying to test a 32 bit process on a 64 bit machine. which is what I am trying to do. more detailes below, but my question is, can I run valgrind 3.3.1 on a 32 bit process on a 64 bit machine? I tried -valgrind --tool=memcheck --enable-only32bit ./myProgram valgrind --enable-only32bit --tool=memcheck ./myProgram and got same error. do I need to recompile with 32 bit only? Which older valgrind will run on a 64 bit machine and test a 32 bit process? my program, $file /path/to/myProgram : ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped my system. $ uname -r 2.6.9-55.ELsmp $uname -p x86_64 $uname -a Linux yyy.zzz.private.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux ValGrind $ valgrind --version valgrind-3.3.1 $ valgrind -v -v --tool=memcheck ./myProgram valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory Verbose (twice) does not result in better/more error msg. I did a test and compiled a test.c on one of the pages I found. $ gcc -o test -g test.c $ file ~/test /home/james/test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped $ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test ==30698== Memcheck, a memory error detector. ==30698== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ... ==30698== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==30698== malloc/free: in use at exit: 35 bytes in 2 blocks. I truncated results. but worked fine. same for example, $ valgrind --tool=memcheck ls -la ==5980== Memcheck, a memory error detector. ==5980== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. (truncated by me) any help would be appreciated. Any other Info I can provide, let me know. James |
|
From: <cat...@ch...> - 2008-08-12 19:07:40
|
So after reading all about ... (internet) and going thru the manual. valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory I found one post about trying to test a 32 bit process on a 64 bit machine. which is what I am trying to do. more detailes below, but my question is, can I run valgrind 3.3.1 on a 32 bit process on a 64 bit machine? I tried -valgrind --tool=memcheck --enable-only32bit ./myProgram valgrind --enable-only32bit --tool=memcheck ./myProgram and got same error. do I need to recompile with 32 bit only? Which older valgrind will run on a 64 bit machine and test a 32 bit process? my program, $file /path/to/myProgram : ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped my system. $ uname -r 2.6.9-55.ELsmp $uname -p x86_64 $uname -a Linux yyy.zzz.private.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux ValGrind $ valgrind --version valgrind-3.3.1 $ valgrind -v -v --tool=memcheck ./myProgram valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory Verbose (twice) does not result in better/more error msg. I did a test and compiled a test.c on one of the pages I found. $ gcc -o test -g test.c $ file ~/test /home/james/test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped $ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test ==30698== Memcheck, a memory error detector. ==30698== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ... ==30698== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==30698== malloc/free: in use at exit: 35 bytes in 2 blocks. I truncated results. but worked fine. same for example, $ valgrind --tool=memcheck ls -la ==5980== Memcheck, a memory error detector. ==5980== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. (truncated by me) any help would be appreciated. Any other Info I can provide, let me know. James |
|
From: Daniel J B. <dan...@gm...> - 2008-08-12 11:22:06
|
A typo prevents use of rpmbuild [1] with the valgrind-3.3.1 release
and tip code, and is addressed by corrections [2] to the RPM spec
file.
Let me know if this won't get committed and I should go via an alternate route.
Many thanks,
Daniel
--- [1]
$ ./configure
$ rpmbuild -ba valgrind.spec
[snip]
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.50892
+ cp -pr 'docs.installed/*.html' 'docs.installed/*.gif'
/var/tmp/valgrind-root/usr/share/doc/valgrind-3.3.1
cp: cannot stat `docs.installed/*.html': No such file or directory
cp: cannot stat `docs.installed/*.gif': No such file or directory
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.50892 (%doc)
--- [2]
diff -ur valgrind-orig/valgrind.spec.in valgrind/valgrind.spec.in
--- valgrind-orig/valgrind.spec.in 2008-08-12 11:41:06.053222000 +0100
+++ valgrind/valgrind.spec.in 2008-08-12 11:42:24.565735000 +0100
@@ -40,7 +40,7 @@
%files
%defattr(-,root,root)
%doc ACKNOWLEDGEMENTS AUTHORS COPYING FAQ.txt INSTALL NEWS README*
-%doc docs.installed/*.html docs.installed/*.gif
+%doc docs.installed/html/*.html docs.installed/html/images/*.png
%{_bindir}/*
%{_includedir}/valgrind
%{_libdir}/valgrind
--
Daniel J Blueman
|
|
From: Nicholas N. <nj...@cs...> - 2008-08-12 05:14:28
|
On Mon, 11 Aug 2008, Anirban Jana wrote: > I am a new user of Valgrind. I just intalled Valgrind-3.3.1 on a Cray XT3 > (AMD Opteron processors, Catamount OS on the compute nodes, SuSE Linux on the > front ends). When running "make regtest" I got a few errors, that are listed > below at the end of the email. Can you please advise me on whether I can > afford to ignore these errors? I mainly plan to begin by using the memcheck > utility, although I may use some of the other utilities later. Let me know if > more information is needed. Ignoring them should be fine, some of the tests aren't totally reliable, and at least some of the same tests fail on my machine. If you're really interested, you can look at the *.diff files for those tests to see how wrong they are. In a lot of cases it'll hopefully just be minor differences. Nick |
|
From: 9. <93...@qq...> - 2008-08-12 01:40:39
|
command-line: valgrind --tool=massif -v --max-snapshots=200 --stacks=yes /data/stone/minisvr/bin/minisvr -f /data/stone/minisvr/ini/auxind.ini -d Massif's output as flowings: ==23204== Massif, a heap profiler. ==23204== Copyright (C) 2003-2007, and GNU GPL'd, by Nicholas Nethercote ==23204== Using LibVEX rev 1854, a library for dynamic binary translation. ==23204== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==23204== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==23204== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==23204== --23204-- Command line --23204-- /data/stone/minisvr/bin/minisvr --23204-- -f --23204-- /data/stone/minisvr/ini/auxind.ini --23204-- -d --23204-- Startup, with flags: --23204-- --tool=massif --23204-- -v --23204-- --max-snapshots=200 --23204-- --stacks=yes --23204-- Contents of /proc/version: --23204-- Linux version 2.6.16.46-0.12-xenpae-1024-18 (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #31 SMP Wed Oct 24 21:10:58 CST 2007 --23204-- Arch and hwcaps: X86, x86-sse1-sse2 --23204-- Page sizes: currently 4096, max supported 4096 --23204-- Valgrind library directory: /usr/local/lib/valgrind --23204-- Massif: alloc-fns: --23204-- Massif: 0: malloc --23204-- Massif: 1: __builtin_new --23204-- Massif: 2: operator new(unsigned) --23204-- Massif: 3: operator new(unsigned long) --23204-- Massif: 4: __builtin_vec_new --23204-- Massif: 5: operator new[](unsigned) --23204-- Massif: 6: operator new[](unsigned long) --23204-- Massif: 7: calloc --23204-- Massif: 8: realloc --23204-- Massif: 9: memalign --23204-- Massif: 10: operator new(unsigned, std::nothrow_t const&) --23204-- Massif: 11: operator new[](unsigned, std::nothrow_t const&) --23204-- Massif: 12: operator new(unsigned long, std::nothrow_t const&) --23204-- Massif: 13: operator new[](unsigned long, std::nothrow_t const&) --23204-- Reading syms from /lib/ld-2.3.4.so (0x4000000) --23204-- Reading syms from /data/stone/minisvr/bin/minisvr (0x8048000) --23204-- Reading syms from /usr/local/lib/valgrind/x86-linux/massif (0x38000000) --23204-- object doesn't have a dynamic symbol table --23204-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_core.so (0x4017000) --23204-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_massif.so (0x4019000) --23204-- Reading syms from /usr/lib/libmysqlpp.so.2 (0x4029000) --23204-- Reading syms from /data/cvsroot/cftcomm/minixml/build/lib/libminixml.so.1.0.0 (0x406F000) --23204-- Reading syms from /usr/lib/libqqapi.so.1 (0x408B000) --23204-- Reading syms from /usr/lib/libbsapi.so.1 (0x4096000) --23204-- Reading syms from /usr/lib/libcftapi.so.1 (0x409B000) --23204-- Reading syms from /data/cvsroot/thirdparty/log4cpp-0.3.5rc3/build/lib/liblog4cpp.so.4.0.5 (0x41B7000) --23204-- Reading syms from /lib/libdl-2.3.4.so (0x41EC000) --23204-- Reading syms from /lib/libnsl-2.3.4.so (0x41F0000) --23204-- Reading syms from /usr/lib/libz.so.1.2.2 (0x4206000) --23204-- object doesn't have a symbol table --23204-- Reading syms from /lib/libpthread-0.10.so (0x4217000) --23204-- Reading syms from /lib/libcrypt-2.3.4.so (0x4269000) --23204-- Reading syms from /usr/lib/libstdc++.so.5.0.6 (0x4297000) --23204-- object doesn't have a symbol table --23204-- Reading syms from /lib/libm-2.3.4.so (0x434F000) --23204-- Reading syms from /usr/lib/libgcc_s.so.1 (0x4372000) --23204-- object doesn't have a symbol table --23204-- Reading syms from /lib/libc-2.3.4.so (0x437A000) --23204-- Reading syms from /data/cvsroot/thirdparty/mysql-5.0.18/build/lib/mysql/libmysqlclient.so.15.0.0 (0x4497000) --23204-- REDIR: 0x4324cd0 (operator new(unsigned)) redirected to 0x401a310 (operator new(unsigned)) --23204-- REDIR: 0x43db710 (malloc) redirected to 0x4019e70 (malloc) --23204-- REDIR: 0x43db8d0 (free) redirected to 0x401ace0 (free) --23204-- REDIR: 0x4324e20 (operator new[](unsigned)) redirected to 0x401a890 (operator new[](unsigned)) --23204-- REDIR: 0x4323740 (operator delete(void*)) redirected to 0x401b050 (operator delete(void*)) --23204-- REDIR: 0x43237a0 (operator delete[](void*)) redirected to 0x401b470 (operator delete[](void*)) --23204-- REDIR: 0x43dbfa0 (calloc) redirected to 0x401b730 (calloc) --23204-- Reading syms from /data/stone/minisvr/lib/libaddcftqqtrans.so (0x48F2000) --23204-- Reading syms from /data/stone/minisvr/lib/libcertusersearchtrans.so (0x4906000) --23204-- Reading syms from /data/stone/minisvr/lib/libqueryconftrans.so (0x4917000) --23204-- Reading syms from /data/stone/minisvr/lib/libregistertrans.so (0x4934000) --23204-- Reading syms from /data/stone/minisvr/lib/libregquerytrans.so (0x4958000) --23204-- Reading syms from /data/stone/minisvr/lib/libregupdatetrans.so (0x497F000) --23204-- Reading syms from /lib/libnss_files-2.3.4.so (0x401E000) --23204-- REDIR: 0x43db990 (realloc) redirected to 0x401b810 (realloc) Massif: ms_main.c:1694 (update_stack_stats): Assertion 'stacks_szB >= -stack_szB_delta' failed. ==23215== at 0x380050AA: report_and_quit (m_libcassert.c:140) ==23215== by 0x3800521D: vgPlain_assert_fail (m_libcassert.c:200) ==23215== by 0x380020DD: update_stack_stats (ms_main.c:1697) ==23215== by 0x380021A4: die_mem_stack (ms_main.c:1717) ==23215== by 0x38010CFA: vgPlain_unknown_SP_update (m_stacks.c:248) ==23215== by 0x62E2FA48: ??? ==23215== by 0x9: ??? ==23215== by 0x59: ??? sched status: running_tid=8 Thread 1: status = VgTs_WaitSys ==23215== at 0x4401F76: nanosleep (in /lib/libc-2.3.4.so) ==23215== by 0x80818E3: main (minisvr.cpp:175) Thread 2: status = VgTs_WaitSys ==23215== at 0x442AEB1: loser_poll (in /lib/libc-2.3.4.so) ==23215== by 0x442AE38: poll (in /lib/libc-2.3.4.so) ==23215== by 0x421C9EF: __pthread_manager (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 3: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 4: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 5: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 6: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 7: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 8: status = VgTs_Runnable ==23215== at 0x421BD69: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 9: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 10: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 11: status = VgTs_WaitSys ==23215== at 0x42233E8: recv (in /lib/libpthread-0.10.so) ==23215== by 0x807D4BD: CRcvThread::RcvPack(std::string&) (rcvthread.cpp:154) ==23215== by 0x807D301: CRcvThread::Run() (rcvthread.cpp:114) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 12: status = VgTs_WaitSys ==23215== at 0x421F9F3: __pthread_sigsuspend (in /lib/libpthread-0.10.so) ==23215== by 0x421EF87: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so) ==23215== by 0x421BCD7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-0.10.so) ==23215== by 0x807D879: CTransEnrolMgr::pop(int&) (transenrolmgr.h:69) ==23215== by 0x807D293: CRcvThread::Run() (rcvthread.cpp:101) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Thread 13: status = VgTs_WaitSys ==23215== at 0x42232E8: accept (in /lib/libpthread-0.10.so) ==23215== by 0x807A9F1: CLsnThread::Run() (lsnthread.cpp:65) ==23215== by 0x80C05F3: CUMSPThread::WorkThread(void*) (UMSPThread.cpp:37) ==23215== by 0x421D54D: pthread_start_thread (in /lib/libpthread-0.10.so) ==23215== by 0x4433B89: clone (in /lib/libc-2.3.4.so) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Chris P. <jud...@gm...> - 2008-08-12 00:50:33
|
On closer inspection I don't think the current error I'm seeing is a threading problem. There is some process monitoring SW on our system that is used to start the app in question and expects a callback within a period of time, which with valgrind is well and truly exceeded and the app is started multiple times, causing my error. Now I just need to figure out where to extend that timeout... On Tue, Aug 12, 2008 at 11:59 AM, Chris Packham <jud...@gm...>wrote: > On Tue, Aug 12, 2008 at 11:45 AM, Tom Hughes <to...@co...> wrote: > >> Valgrind does not (these days) replace libpthread, nor does it alter >> the mapping between user and kernel threads. There is still one kernel >> thread for each pthread you create - the only change is the order in >> which they execute and how many may execute at once. > > > OK, I understand this now. > > If your program is reliant on the order in which threads execute or how >> many threads execute at once then it is, by definition, broken. > > > Yes its definitely not in a good state. I was just hoping not to have to > deal with the threading issues at this point. I guess I may just have to fix > those first. > |
|
From: Chris P. <jud...@gm...> - 2008-08-11 23:59:28
|
On Tue, Aug 12, 2008 at 11:45 AM, Tom Hughes <to...@co...> wrote: > Valgrind does not (these days) replace libpthread, nor does it alter > the mapping between user and kernel threads. There is still one kernel > thread for each pthread you create - the only change is the order in > which they execute and how many may execute at once. OK, I understand this now. If your program is reliant on the order in which threads execute or how > many threads execute at once then it is, by definition, broken. Yes its definitely not in a good state. I was just hoping not to have to deal with the threading issues at this point. I guess I may just have to fix those first. |
|
From: Tom H. <to...@co...> - 2008-08-11 23:45:37
|
In message <a03...@ma...>
"Chris Packham" <jud...@gm...> wrote:
> I read http://valgrind.org/docs/manual/manual-core.html#manual-core.pthreadsand
> interpreted this as valgrind supplies its own pthreads.
>
> "Valgrind schedules your program's threads in a round-robin fashion, with
> all threads having equal priority." I guess this means even if it doesn't
> supply its own pthreads implementation it does alter the scheduling.
>
> I concluded, perhaps erroneously, that threading was causing my problems.
> What I'm really after is any guidance on running valgrind with a memory and
> CPU constrained environment.
No, what that is saying is that valgrind effectively overrides the
kernel's normal scheduling of the threads and forces them to execute
one at a time in round-robin fashion.
Valgrind does not (these days) replace libpthread, nor does it alter
the mapping between user and kernel threads. There is still one kernel
thread for each pthread you create - the only change is the order in
which they execute and how many may execute at once.
If your program is reliant on the order in which threads execute or how
many threads execute at once then it is, by definition, broken.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Chris P. <jud...@gm...> - 2008-08-11 23:01:40
|
I read http://valgrind.org/docs/manual/manual-core.html#manual-core.pthreadsand interpreted this as valgrind supplies its own pthreads. "Valgrind schedules your program's threads in a round-robin fashion, with all threads having equal priority." I guess this means even if it doesn't supply its own pthreads implementation it does alter the scheduling. I concluded, perhaps erroneously, that threading was causing my problems. What I'm really after is any guidance on running valgrind with a memory and CPU constrained environment. On Mon, Aug 11, 2008 at 6:58 PM, Tom Hughes <to...@co...> wrote: > Chris Packham wrote: > > When I run it under valgrind I start getting some random failures (program >> failures not valgrind reporting). I'm currently putting this down to the >> fact that valgrind supplies its own pthread implementation. >> > > Valgrind hasn't provided it's own pthread implementation for several years, > so if you are really using a version has it's own libpthread then the first > thing you need to do is upgrade. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |
|
From: Chris P. <jud...@gm...> - 2008-08-11 22:53:41
|
I've used valgrind 3.2.3 and 3.3.1 both with the same result. I want to use memcheck but I'm not explicitly passing --tool=memcheck (from reading the documentation memcheck should be selected by default). On Mon, Aug 11, 2008 at 6:17 PM, Bart Van Assche <bar...@gm...>wrote: > On Mon, Aug 11, 2008 at 4:57 AM, Chris Packham <jud...@gm...> > wrote: > > I've used valgrind successfully on a number of applications running on > our > > embedded linux system and I'm now running into problems with one > particular > > application. It is a huge 3rd party app which for legal reasons I can't > > disclose much about, but I can say that I makes use of a large number of > > real-time threads and some kernel-to-user shared memory. > > > > When I run it under valgrind I start getting some random failures > (program > > failures not valgrind reporting). I'm currently putting this down to the > > fact that valgrind supplies its own pthread implementation. > > > > I really only want to use the malloc debugging features of memcheck so at > > this point I'm not interested in using the thread debugging of helgrind. > I > > found an old post > > http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where > someone > > had inadvertently turned this feature off. > > > > Does anyone know a way of turning of valgrind's thread library in a > > controlled fashion? Is this even a good idea? > > Which Valgrind version do you use, and which Valgrind tool do you use ? > > Bart. > |
|
From: Anirban J. <an...@ps...> - 2008-08-11 19:58:01
|
Hi, I am a new user of Valgrind. I just intalled Valgrind-3.3.1 on a Cray XT3 (AMD Opteron processors, Catamount OS on the compute nodes, SuSE Linux on the front ends). When running "make regtest" I got a few errors, that are listed below at the end of the email. Can you please advise me on whether I can afford to ignore these errors? I mainly plan to begin by using the memcheck utility, although I may use some of the other utilities later. Let me know if more information is needed. Thanks in advance Anirban ************************** Errors from regtest ------------------- == 338 tests, 25 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Felix S. <fel...@we...> - 2008-08-11 14:47:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear, is there any possibility for thread scheduling in valgrind? Do you have a tutorial or example, please? Regards fs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkigUP8ACgkQmH8OAwYoDBlHmQCgjwRnchjMNt00poTcarhTR/De VEoAoLTWKigioiCDFZN6q/SvoXhUX2vJ =fvVh -----END PGP SIGNATURE----- |
|
From: Tom H. <to...@co...> - 2008-08-11 06:58:06
|
Chris Packham wrote: > When I run it under valgrind I start getting some random failures > (program failures not valgrind reporting). I'm currently putting this > down to the fact that valgrind supplies its own pthread implementation. Valgrind hasn't provided it's own pthread implementation for several years, so if you are really using a version has it's own libpthread then the first thing you need to do is upgrade. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bart V. A. <bar...@gm...> - 2008-08-11 06:16:56
|
On Mon, Aug 11, 2008 at 4:57 AM, Chris Packham <jud...@gm...> wrote: > I've used valgrind successfully on a number of applications running on our > embedded linux system and I'm now running into problems with one particular > application. It is a huge 3rd party app which for legal reasons I can't > disclose much about, but I can say that I makes use of a large number of > real-time threads and some kernel-to-user shared memory. > > When I run it under valgrind I start getting some random failures (program > failures not valgrind reporting). I'm currently putting this down to the > fact that valgrind supplies its own pthread implementation. > > I really only want to use the malloc debugging features of memcheck so at > this point I'm not interested in using the thread debugging of helgrind. I > found an old post > http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where someone > had inadvertently turned this feature off. > > Does anyone know a way of turning of valgrind's thread library in a > controlled fashion? Is this even a good idea? Which Valgrind version do you use, and which Valgrind tool do you use ? Bart. |
|
From: Chris P. <jud...@gm...> - 2008-08-11 02:57:33
|
Hi, I've used valgrind successfully on a number of applications running on our embedded linux system and I'm now running into problems with one particular application. It is a huge 3rd party app which for legal reasons I can't disclose much about, but I can say that I makes use of a large number of real-time threads and some kernel-to-user shared memory. When I run it under valgrind I start getting some random failures (program failures not valgrind reporting). I'm currently putting this down to the fact that valgrind supplies its own pthread implementation. I really only want to use the malloc debugging features of memcheck so at this point I'm not interested in using the thread debugging of helgrind. I found an old post http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where someone had inadvertently turned this feature off. Does anyone know a way of turning of valgrind's thread library in a controlled fashion? Is this even a good idea? Thanks, Chris |
|
From: Venkatesh T. <cst...@gm...> - 2008-08-10 07:39:21
|
Hi, I am sure this topic has been beaten to death, or atleast i am guessing. But i could'nt find it using search on the archives. I see a message that says valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory Now i installed without setting prefix with configure. And valgrind was installed to /usr/local/bin . I thought memcheck is installed as part of make install in valgrind's root folder? Anyone know the cause of this error? and the solution? Would really appreciate any help. :) Thank You Venk |
|
From: Felix S. <fel...@we...> - 2008-08-08 12:21:22
|
Dear, i want to implement shadow values. where should I add shadow values to programm memory space? And how can i do that? do you have some tutorials or easy examples, not so complicated such as memcheck? Greetings Felix |
|
From: Josef W. <Jos...@gm...> - 2008-08-08 11:01:28
|
On Friday 08 August 2008, Anish Anto wrote: > However, i have been finding that my App. which for a normal single run > takes total 10 secs(cpu time) and one of its functions FUN() takes 0.98 > secs(cpu time)- thats 10% of total cpu time , however when run with > Valgrind like this valgrind --tool=callgrind ./Release/MYAPP, takes about > total 600 secs and the function FUN() takes about 200 secs - thats 33% of > the total cputime. As already said, runtime instrumentation as done by Valgrind totally perturbates time behavior of the application, so any wallclock measurement done within a Valgrind run is bogus. However, Cachegrind/Callgrind does not do any such wallclock measurement but only count synthetic cache events like hits/misses and instruction executions, so ... > Kcachegrind does show me that percentage of time spend > at FUN() as 33%, which is true when app is run using Valgrind, however > just 10% when run without using Valgrind/Kcachegrind. ... I do not understand what "time" you are talking about here. KCachegrind does have a derived event type "estimated cycle time", which is calculated very roughly from the events counted, but you can not really expect this to have much relation to reality. As this only takes cache hits/misses into account, it is only kind of valid if (1) the runtime of your program is heavily influenced by bad cache behavior (it can not say anything about cycles wasted in branch misprediction, pipeline conflicts, bus congestions) (2) the coefficients of the "estimated cycle time" formula for average stall times of L1/L2 misses are adjusted to your system (the default is 100 cycles for L2 miss, and 10 cycles for L1 miss) You always also should use real time measurements to check any improvements. Callgrind/Cachegrind can just gave hints about potential time wasters in your code. Josef > Well, its understandable that running app using Valgrind has an additional > overhead - hence 600 secs CPU time with valgrind is compared with 10 secs > CPU time without valgrind. > However, my assumption was that the realtive percentage usage within the > functions should have remained the same , -eg 10% usage at function FUN(), > should have remained exactly 10% even on running valgrind, however why > does Valgrind/Kcachegrind show me as 33% ? > > Thanks > Anish > > > |