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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(25) |
2
(24) |
3
(6) |
4
(2) |
5
(4) |
|
6
(5) |
7
(19) |
8
(18) |
9
(7) |
10
(13) |
11
(6) |
12
(8) |
|
13
(4) |
14
(5) |
15
(8) |
16
(4) |
17
(2) |
18
(2) |
19
(6) |
|
20
(14) |
21
(6) |
22
(20) |
23
(13) |
24
(3) |
25
(5) |
26
|
|
27
(4) |
28
(7) |
29
(14) |
30
(6) |
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-21 17:19:55
|
On Mon, 21 Nov 2005, Dirk Reiners wrote: > I mainly use Addrcheck because of a combination of 1 and 3. 1 should be > obvious, 3 because there are a bunch of warnings that cannot be > suppressed for Memcheck when using the nVidia 3D graphics driver. With > the latest version that has gotten better, as they only appear during > the startup of my program, so right now I could live without Addrcheck. By "latest version" do you mean the latest version of the drivers, or of Valgrind? > However, that might change as my program and the nVidia drivers develop, > so it would be nice if there was a way to do more general suppressions > for Memcheck, which would allow me to ignore Addrcheck altogether. Thanks for the info. Can you remind me why the nVidia driver errors are hard to suppress? Is it because they are lacking debug info and/or symbols? Nick |
|
From: Dirk R. <dre...@ia...> - 2005-11-21 17:13:22
|
On Friday 18 November 2005 21:23, Nicholas Nethercote wrote: > Hi, > > So I'd like to know why people who use Addrcheck do so in preference > to Memcheck. I can think of four possible reasons: > > 1. Addrcheck is faster > 2. Addrcheck uses less memory > 3. Addrcheck does not issue undefined value error messages > 4. Something else I haven't thought of I mainly use Addrcheck because of a combination of 1 and 3. 1 should be obvious, 3 because there are a bunch of warnings that cannot be suppressed for Memcheck when using the nVidia 3D graphics driver. With the latest version that has gotten better, as they only appear during the startup of my program, so right now I could live without Addrcheck. However, that might change as my program and the nVidia drivers develop, so it would be nice if there was a way to do more general suppressions for Memcheck, which would allow me to ignore Addrcheck altogether. Just my .02$ Dirk |
|
From: Dennis L. <pla...@in...> - 2005-11-20 23:23:57
|
At 00:02 21.11.2005, Tom Hughes wrote: >In message <6.1...@po...> > Dennis Lubert <pla...@in...> wrote: > > > can I somehow to get valgrind to obey the settings of > > /proc/sys/kernel/core_uses_pid and core_pattern ? > >No. The first could be done, but the second is tricker as we need >to differentiate core dumps from valgrind itself and those from the >client it is running. > >Hence the core.<pid> vs vgcore.<pid> differentiation. maybe vg could be prepended to the actual file name ? Like in my case I have core_pattern = /var/core/core.%p_sig%s_at_%t_from_%e_%u_%g to keep information about the program that crashed in the filename and to have them all at the same location, for easier cleanup. maybe valgrind could rewrite it to /var/core/vgcore.%p_sig%s_at_%t_from_%e_%u_%g and dump it there ? greets Dennis Carpe quod tibi datum est |
|
From: Nicholas N. <nj...@cs...> - 2005-11-20 23:23:14
|
On Sun, 20 Nov 2005, Tom Hughes wrote: >> can I somehow to get valgrind to obey the settings of >> /proc/sys/kernel/core_uses_pid and core_pattern ? > > No. The first could be done, but the second is tricker as we need > to differentiate core dumps from valgrind itself and those from the > client it is running. > > Hence the core.<pid> vs vgcore.<pid> differentiation. Could we just append "vg" in front of whatever name would be used? Ideally any core file for the client would get the normal name, and any core file for Valgrind itself would get a different name (eg. with the "vg" prefix), but I don't see how that's possible. Nick |
|
From: Tom H. <to...@co...> - 2005-11-20 23:02:46
|
In message <6.1...@po...>
Dennis Lubert <pla...@in...> wrote:
> can I somehow to get valgrind to obey the settings of
> /proc/sys/kernel/core_uses_pid and core_pattern ?
No. The first could be done, but the second is tricker as we need
to differentiate core dumps from valgrind itself and those from the
client it is running.
Hence the core.<pid> vs vgcore.<pid> differentiation.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2005-11-20 22:19:54
|
Hi, can I somehow to get valgrind to obey the settings of /proc/sys/kernel/core_uses_pid and core_pattern ? greets Dennis Carpe quod tibi datum est |
|
From: Julian S. <js...@ac...> - 2005-11-20 20:08:20
|
On Sunday 20 November 2005 19:58, Yeshurun, Meir wrote:
> Could it be because a thread terminated and its stack was freed?
>
> I thought the message means that the A bits of 148823752 consecutive
> bytes were changed to indicate invalid addresses ("a 0").
The encoding is backwards: 0 = valid, 1 = invalid. Hence this is an
area which is addressible but undefined, most likely the result of
doing malloc.
J
|
|
From: Yeshurun, M. <mei...@in...> - 2005-11-20 19:58:58
|
Could it be because a thread terminated and its stack was freed?
I thought the message means that the A bits of 148823752 consecutive
bytes were changed to indicate invalid addresses ("a 0").
Thanks,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of
Nicholas Nethercote
Sent: Sunday, November 20, 2005 7:28 PM
To: Tom Hughes
Cc: val...@li...
Subject: Re: [Valgrind-users] address range perms?
On Sun, 20 Nov 2005, Tom Hughes wrote:
>> Warning: set address range perms: large range 148823752, a 0, v 1
>
> It means that the addressability and/or definedness flags for a
> large area were changed in one go - the area has to be close to
> 100Mb in size before the warning triggers.
>
> It can sometimes be legitimate, but can sometimes indicate a problem.
And "problem" here is as likely to be a problem with Valgrind as it is a
problem with your program. You probably don't need to worry about it.
Is it likely that your program allocated 148MB at once, eg. on the heap?
Nick
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-20 17:27:45
|
On Sun, 20 Nov 2005, Tom Hughes wrote: >> Warning: set address range perms: large range 148823752, a 0, v 1 > > It means that the addressability and/or definedness flags for a > large area were changed in one go - the area has to be close to > 100Mb in size before the warning triggers. > > It can sometimes be legitimate, but can sometimes indicate a problem. And "problem" here is as likely to be a problem with Valgrind as it is a problem with your program. You probably don't need to worry about it. Is it likely that your program allocated 148MB at once, eg. on the heap? Nick |
|
From: Tom H. <to...@co...> - 2005-11-20 16:39:27
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> What does this warning message from Memcheck mean?
>
> Warning: set address range perms: large range 148823752, a 0, v 1
It means that the addressability and/or definedness flags for a
large area were changed in one go - the area has to be close to
100Mb in size before the warning triggers.
It can sometimes be legitimate, but can sometimes indicate a problem.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-11-20 16:24:14
|
Hi,=20 =20 What does this warning message from Memcheck mean? =20 Warning: set address range perms: large range 148823752, a 0, v 1 =20 Thanks, Meir |
|
From: Chris J. <jo...@he...> - 2005-11-20 15:32:21
|
Hi there, On Sunday 20 Nov 2005 3:13 pm, Tom Hughes wrote: > In message <200...@he...> > > Chris Jones <jo...@he...> wrote: > > Any suggestions ? Is it a problem with valgrind or the library its trying > > to load ? > > Technically probably valgrind, but moving the library to a different > fileystem may work around it. yes, this seems to be the case. I suspected it could be due to AFS, so ran a few more tests and so far all seem OK now and cachegrind runs just fine. The .so file is still on AFS, but now is cached locally whereas in the first run all AFS files needed loading from the remote server. Possibly the delay this introduced caused the problems ? > Can you try stracing valgrind and see if there is a stat call returning > an error just before that message and what the error is? Unfortunately, I cannot seem to get the error again now that I want to - such is life ... If I do run into this again, I'll try and do what you suggest. cheers Chris |
|
From: Tom H. <to...@co...> - 2005-11-20 15:29:51
|
In message <01a...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@he...>
> Chris Jones <jo...@he...> wrote:
>
> > --6614-- Reading syms
> > from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so
> > (0xAABE000)
> > --6614-- Reading syms
> > from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so
> > (0xAB2A000)
> > --6614-- Can't stat .so/.exe (to determine its size)?!
>
> That's interesting because I thought I had fixed the primary cause
> of this problem, namely use the stat family of system calls instead
> of the stat64 ones.
It turns out I hadn't fixed the one in the debug info reader. Try this
patch and see if it helps.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-20 15:13:32
|
In message <200...@he...>
Chris Jones <jo...@he...> wrote:
> Any suggestions ? Is it a problem with valgrind or the library its trying to
> load ?
Technically probably valgrind, but moving the library to a different
fileystem may work around it.
> --6614-- Reading syms
> from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so
> (0xAABE000)
> --6614-- Reading syms
> from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so
> (0xAB2A000)
> --6614-- Can't stat .so/.exe (to determine its size)?!
That's interesting because I thought I had fixed the primary cause
of this problem, namely use the stat family of system calls instead
of the stat64 ones.
Can you try stracing valgrind and see if there is a stat call returning
an error just before that message and what the error is?
I suspect that moving that file off AFS and onto a convential file
system will work around this though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-11-20 14:53:26
|
On Friday 18 November 2005 21:23, Nicholas Nethercote wrote: > 1. Addrcheck is faster Biggest reason. you want to quickly find out where you corrupt the heap. undefined value access check is usually not that important. Dirk |
|
From: Chris J. <jo...@he...> - 2005-11-20 14:12:51
|
Hi, > Try the current code from the repository (see > http://www.valgrind.org/downloads/repository.html) or wait a few days for > 3.1.0 to come out -- the problem should be fixed in either case. Thanks for the info. After some playing around I finally got the current SVN version compiled (subversion was missing on the machine ..) However, I now get the error below. Any suggestions ? Is it a problem with valgrind or the library its trying to load ? cheers Chris --6614-- Reading syms from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so (0xAABE000) --6614-- Reading syms from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so (0xAB2A000) --6614-- Can't stat .so/.exe (to determine its size)?! ==6614== ==6614== Process terminating with default action of signal 6 (SIGABRT): dumping core ==6614== at 0x59ACEEF: raise (in /lib/tls/libc-2.3.2.so) ==6614== by 0x59AE6F4: abort (in /lib/tls/libc-2.3.2.so) ==6614== by 0x59324C6: (within /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5932513: std::terminate() (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5932685: __cxa_throw (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x58EBABF: std::__throw_logic_error(char const*) (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x59259C6: (within /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5921C13: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x4EC4A51: System::getErrorString(unsigned long) (System.cpp:263) ==6614== by 0x4EC4986: System::getLastErrorString() (System.cpp:237) ==6614== by 0x75C00FA: PoolDbCacheSvc::i_loadDictionary(std::string const&) (PoolDbCacheSvc.cpp:354) ==6614== by 0x75BFB83: PoolDbCacheSvc::loadLibraries() (PoolDbCacheSvc.cpp:298) > > Nick > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- +--------------------------------------------------------------+ | Dr Chris R Jones work : +44 (0)1223 337324 | | HEP Group (rm 882) fax : +44 (0)1223 353920 | | Cavendish Laboratory, home : +44 (0)1223 510711 | | Madingley Road, mobile : +44 (0)7723 327477 | | Cambridge, CB3 0HE email : jo...@he... | +--------------------------------------------------------------+ |
|
From: Nicholas N. <nj...@cs...> - 2005-11-19 21:29:49
|
On Sat, 19 Nov 2005, Chris Jones wrote: > The problem I have is with the code profiling tool cachegrind. If I run the > standard memcheck tool, it runs fine, but with cachegrind (which is what I am > interested in) I get > > VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. > VG_(get_memory_from_mmap): 240105984 bytes already allocated. Try the current code from the repository (see http://www.valgrind.org/downloads/repository.html) or wait a few days for 3.1.0 to come out -- the problem should be fixed in either case. Nick |
|
From: Chris J. <jo...@he...> - 2005-11-19 21:25:22
|
Hi, I am trying to get the code profiling tool cachegrind working with an application I am working on. I successfully used older versions (pre 2) with eariler iterations of the application on at that time redhat 7.3, but have been having problems with version 2.0.0 onwards on scientific linux 3 (essential Redhat Enterprise 3 with some additions, see https://www.scientificlinux.org/ for details if you are interested). The problem I have is with the code profiling tool cachegrind. If I run the standard memcheck tool, it runs fine, but with cachegrind (which is what I am interested in) I get VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. VG_(get_memory_from_mmap): 240105984 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. the full output is here http://www.hep.phy.cam.ac.uk/~jonesc/valgrind-cachegrind.log Which seems to suggest the machine does not have enough memory ? However, the application is running on a box with 2G ram and 2G swap, and normally only requires around 100M to run, so this seems strange ? Is there a bug here, or is it really the case that cachegrind cannot run with this app. That would be a real shame as I found it really useful in the past. Are there any options I can use to reduce the memory usage ? cheers Chris |
|
From: Nicholas N. <nj...@cs...> - 2005-11-19 20:53:03
|
On Sat, 19 Nov 2005, ERIC BERGER, BLOOMBERG/ TEL AVIV wrote: > I'm hoping that someone with the right knowledge of the relevant issues > could succeed in porting valgrind fairly quickly. See http://www.valgrind.org/info/platforms.html, under "Porting Plans". Nick |
|
From: ERIC B. B. T. A. <eb...@bl...> - 2005-11-19 20:09:33
|
In the past I have successfully used valgrind in a Redhat Linux system. Currently I am experimenting with the GNU/Interix/Microsoft-Services-for-Unix platform. Interix has ported hundreds of GNU packages to the Interix/MS-SFU environment. See http://www.microsoft.com/technet /interopmigration/unix/sfu/default.mspx for information about MS-SFU and http://www.interopsystems.com for information about Interix and the Interix Toolworks. Unfortunately, valgrind is not in the list of packages ported to GNU/Interix/MS-SFU. I tried downloading valgrind and building it in the GNU/Interix/MS-SFU environment, but I got bogged down in various configure (e.g. glibc version) and compiler complaints (a.out.h is needed and missing). I'm hoping that someone with the right knowledge of the relevant issues could succeed in porting valgrind fairly quickly. Thanks, Eric |
|
From: Dennis L. <pla...@in...> - 2005-11-19 11:47:24
|
At 21:23 18.11.2005, Nicholas Nethercote wrote: >Hi, > >So I'd like to know why people who use Addrcheck do so in preference to >Memcheck. I can think of four possible reasons: > > 1. Addrcheck is faster > 2. Addrcheck uses less memory > 3. Addrcheck does not issue undefined value error messages > 4. Something else I haven't thought of I was always using memcheck for running my programs, and only switched to addrcheck when memcheck failed, mostly due to out of memory with memcheck. So 2. was the most important reason to me to use it. I never felt for my programs running under addrcheck was really much faster, but that was probably due to much i/o wait. For 3. Id say that would no be (the only) reason to resurrect addrcheck, just run memcheck with --suppress-all-underfined-value-error-messages or whatever. Whenever I had to use addrcheck, it felt harder to track down actual errors, as addrcheck output seemed not so good as memchecks. Personally, I would not miss addrcheck much.. greets Dennis Carpe quod tibi datum est |
|
From: <Woe...@on...> - 2005-11-19 09:36:43
|
On Friday 18 November 2005 21:23, Nicholas Nethercote wrote: > Hi, > > So I'd like to know why people who use Addrcheck do so in preference > to Memcheck. I can think of four possible reasons: > > 1. Addrcheck is faster > 2. Addrcheck uses less memory > 3. Addrcheck does not issue undefined value error messages > 4. Something else I haven't thought of I only used Addrcheck when I was looking for memory leaks. Then nothing=20 but 1. was important for me. Cheers, Andr=E9 |
|
From: Brian C. <cr...@fi...> - 2005-11-18 20:32:38
|
For me it was the memory issue, and in 2.4 the speed issue. Memcheck in 3.0 seems significantly faster anyway, so those are all I care about. #3 can be fixed with suppressions, so I say ditch addrcheck. :) -- Brian Nicholas Nethercote wrote: > Hi, > > Addrcheck has not worked since Valgrind 2.4.0. A number of people have > complained about this, and we'd like to reinstate it, or reinstate > something like it. On the other hand, it would be great if we could get > rid of Addrcheck and just use Memcheck because that would be less code > to maintain. > > So I'd like to know why people who use Addrcheck do so in preference to > Memcheck. I can think of four possible reasons: > > 1. Addrcheck is faster > 2. Addrcheck uses less memory > 3. Addrcheck does not issue undefined value error messages > 4. Something else I haven't thought of > > Which of these reasons are important will affect possible solutions. For > example, we're considering the idea of using a compressed V bit scheme > that would reduce the overhead of shadow memory in Memcheck (the main > memory overhead) from 112.5% to about 25%. (Addrcheck's overhead is > 12.5%.) If reason (2) is the main reason people prefer Addrcheck, then > compressed V bits should be enough of an improvement to Memcheck that > Addrcheck is no longer necessary. But if reason (1) is the main reason, > then maybe not. > > So, Addrcheck users, please speak up! There are a lot of you... the > recent survey (which I've almost finished analysing) shows that around > 25% of Valgrind users use Addrcheck. Tell me which one (or more) of the > above reasons is important to you. Your feedback will help with the > task of getting Addrcheck or an acceptable equivalent working. If you > don't want to reply to the list, please email me privately. > > Thanks. > > Nick > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Nicholas N. <nj...@cs...> - 2005-11-18 20:24:04
|
Hi, Addrcheck has not worked since Valgrind 2.4.0. A number of people have complained about this, and we'd like to reinstate it, or reinstate something like it. On the other hand, it would be great if we could get rid of Addrcheck and just use Memcheck because that would be less code to maintain. So I'd like to know why people who use Addrcheck do so in preference to Memcheck. I can think of four possible reasons: 1. Addrcheck is faster 2. Addrcheck uses less memory 3. Addrcheck does not issue undefined value error messages 4. Something else I haven't thought of Which of these reasons are important will affect possible solutions. For example, we're considering the idea of using a compressed V bit scheme that would reduce the overhead of shadow memory in Memcheck (the main memory overhead) from 112.5% to about 25%. (Addrcheck's overhead is 12.5%.) If reason (2) is the main reason people prefer Addrcheck, then compressed V bits should be enough of an improvement to Memcheck that Addrcheck is no longer necessary. But if reason (1) is the main reason, then maybe not. So, Addrcheck users, please speak up! There are a lot of you... the recent survey (which I've almost finished analysing) shows that around 25% of Valgrind users use Addrcheck. Tell me which one (or more) of the above reasons is important to you. Your feedback will help with the task of getting Addrcheck or an acceptable equivalent working. If you don't want to reply to the list, please email me privately. Thanks. Nick |
|
From: Carsten F.
|
Hello all, I just wanted to say a big *Thanks!!* for valgrind! Today was already the second time that it showed me problems in my program that I'd *never* found otherwise (or maybe only after months, rather than after just a few minutes). In fact, I don't know of any free or commercial tool that can do similar. Thank you very much, and keep up the good work! Best, Carsten -- Ca3D - Engine http://www.Ca3D-Engine.de Carsten Fuchs http://www.Ca3D-Engine.de/c_Carsten.php |