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
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2006-01-25 22:45:42
|
> One problem is that Valgrind's client requests currently have a maximum of > four arguments. Pretty harmless. All the args are passed in a block in memory to avoid getting tangled in an args-in-registers style swamp, so that block can easily be expanded by one word to accommodate an extra argument. J |
|
From: Nicholas N. <nj...@cs...> - 2006-01-25 22:15:24
|
On Wed, 25 Jan 2006, Joe Mason wrote: > The easiest modification to valgrind would be to reinstate GET_VBITS and > SET_VBITS, I guess. Or I could add VALGRIND_REALLOCLIKE_BLOCK(oldaddr, > newaddr, newsize, rz, is_zeroed), where is_zeroed applies only to any > newly allocated memory. Or VALGRIND_RESIZE_MALLOCLIKE_BLOCK(addr, > newsize, rz, is_zeroed), which would only change the size of a malloc'd > block (so only useful for the in-place case). GET_VBITS/SET_VBITS is > most general, but RESIZE_MALLOCLIKE_BLOCK directly attacks the > shortcoming, which is that once a block is MALLOC'd it can't be changed > without discarding the vbits. And REALLOCLIKE_BLOCK preserves the > symmetry of providing hooks for the 3 standard malloc operations. GET_VBITS and SET_VBITS have been reinstated in the COMPVBITS branch, and will be present in 3.2.0, which will probably be out in a couple of months. However, having REALLOCLIKE_BLOCK as well would be good, because it could apply to any tool, whereas GET_VBITS/SET_VBITS are Memcheck-specific. One problem is that Valgrind's client requests currently have a maximum of four arguments. Perhaps the 'rz' parameter could be not used, and we could assume the redzone is the same size as in the original block. Nick |
|
From: Jorrit T. <jor...@gm...> - 2006-01-25 18:10:02
|
On 1/25/06, Dennis Lubert <pla...@in...> wrote: > At 13:59 25.01.2006, Christian Parpart wrote: > > > Porting VC++ 6.0 code to linux could be a bigger problem though, > > > since it is known to horribly fail to comply to the iso c++ standard, > > > as an example it does not following scoping rules for for-loops and > > > has differente template syntax. > > > >best time to revalidate the sources and make it compliant though ;-) > But then it doest work with VC++6.0 any more *evil laugther* Actually it is possible to make it work on VC++6.0 AND later. In some cases you have to do some tricks but in CS we have always been compatible with VC6 and higher. Of course now we're dropping VC6 support so we can remove a few of those hacks. Greetings, > > greets > > Dennis > > Carpe quod tibi datum est > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=3D649 |
|
From: Dennis L. <pla...@in...> - 2006-01-25 17:59:45
|
At 13:59 25.01.2006, Christian Parpart wrote: > > Porting VC++ 6.0 code to linux could be a bigger problem though, > > since it is known to horribly fail to comply to the iso c++ standard, > > as an example it does not following scoping rules for for-loops and > > has differente template syntax. > >best time to revalidate the sources and make it compliant though ;-) But then it doest work with VC++6.0 any more *evil laugther* greets Dennis Carpe quod tibi datum est |
|
From: Joe M. <jo...@no...> - 2006-01-25 17:41:39
|
I'm implemented in a custom memory manager that has semantics like
malloc, free and realloc. malloc and free are easy to integrate with
valgrind using VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK,
but I'm having some problems with realloc.
There are three cases:
1. Can't realloc in place - need to alloc new memory, copy the old chunk
to the new, and free the old chunk.
- Easy: just call VALGRIND_MALLOCLIKE_BLOCK after creating the new
chunk, then valgrind will notices the memcpy and update its vbits
accordingly, then call VALGRIND_FREELIKE_BLOCK on the old chunk.
2. Able to grow allocation in place - need to mark new area addressable.
- It's tempting to just use VALGRIND_MAKE_WRITABLE to mark the new area
as allocated, but of course then valgrind doesn't have the right size
for the malloc'd chunk: attempts to write past the end of the new
memory get the wrong error message ("Address 0x401F200 is not stack'd,
malloc'd or (recently) free'd" instead of "Address 0x401F200 is 0
bytes after a block of size 128 alloc'd"), and calling
VALGRIND_FREELIKE_BLOCK later will only mark the chunk unaddressable
up to its original size.
3. Able to shrink allocation - need to mark part of old area
unaddressable.
- Again, could just use VALGRIND_MAKE_NOACCESS, but then it wouldn't
correctly track the size of the malloc'd chunk.
The only other option I can see for the two in-place cases is to call
VALGRIND_FREELIKE_BLOCK(ptr); VALGRIND_MALLOCLIKE_BLOCK(ptr, newsize) -
but that throws away all the vbits for the area. I could follow it with
VALGRIND_MAKE_READABLE(ptr, max(oldsize, newsize)), but of course
that assumes that the original chunk was entirely in use.
The obvious thing to do is use VALGRIND_GET_VBITS to save the vbits
before the reallocation, and follow it up with VALGRIND_PUT_VBITS
(truncating the array if necessary). Except I see those two calls were
deprecated last year, and aren't even included valgrind-3.1.0-Debian.
So what are my options? Right now, if compiled in debug mode, I'm
adding an extra memcpy for in-place reallocs (copy the memory to a
holding area, realloc in place, then copy it all back) solely so that
valgrind will notice the copy and keep the vbits up to date, but that's
a horrible solution. Is there anything else I could do without
modifying valgrind? (I took a look at MAC_(realloc), but of course it
uses a lot of internal machinery that's not exposed to users.)
The easiest modification to valgrind would be to reinstate GET_VBITS and
SET_VBITS, I guess. Or I could add VALGRIND_REALLOCLIKE_BLOCK(oldaddr,
newaddr, newsize, rz, is_zeroed), where is_zeroed applies only to any
newly allocated memory. Or VALGRIND_RESIZE_MALLOCLIKE_BLOCK(addr,
newsize, rz, is_zeroed), which would only change the size of a malloc'd
block (so only useful for the in-place case). GET_VBITS/SET_VBITS is
most general, but RESIZE_MALLOCLIKE_BLOCK directly attacks the
shortcoming, which is that once a block is MALLOC'd it can't be changed
without discarding the vbits. And REALLOCLIKE_BLOCK preserves the
symmetry of providing hooks for the 3 standard malloc operations.
Any preferences?
Joe
|
|
From: Benjamin C. <ben...@si...> - 2006-01-25 17:31:37
|
Hello again Funnily enough, throwing more memory at it didn't solve the problem. I was just fooled for a short while. The real problem is that none of UML or Valgrind or my program are running out of memory. Valgrind and my program are running out of memory maps! This fixed it: echo 262144 > /proc/sys/vm/max_map_count And here is where I found the answer: http://uml.harlowhill.com/index.php/Troubleshooting Benjamin Nicholas Nethercote wrote: > On Tue, 24 Jan 2006, Tom Hughes wrote: > >>> The application is a beast taking hundreds of megabytes of dynamic >>> memory. >> >> >> Well that is probably the problem then - error 12 is ENOMEM so most >> likely your program has run out of memory. Don't forget that under >> valgrind it will be using a lot more memory than normal. > > > If you're running Memcheck (the default tool), try running --tool=none, > which will use less memory. > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Benjamin C. <ben...@si...> - 2006-01-25 14:44:06
|
Hi everyone The solution was simple: throw more hardware at it. Bought an extra gigabyte and now things are as happy as they should be. Thanks for responding Ben Nicholas Nethercote wrote: > On Tue, 24 Jan 2006, Tom Hughes wrote: > >>> The application is a beast taking hundreds of megabytes of dynamic >>> memory. >> >> >> Well that is probably the problem then - error 12 is ENOMEM so most >> likely your program has run out of memory. Don't forget that under >> valgrind it will be using a lot more memory than normal. > > > If you're running Memcheck (the default tool), try running --tool=none, > which will use less memory. > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Cees W. <ce...@pc...> - 2006-01-25 13:38:28
|
>> But is there any way of definining something like?:
>>
>> {
>> <insert a suppression name here>
>> Memcheck:Leak
>> fun:_Znwj
>> ?? 1 or more of any functions
>> fun:RootOfAllEvil
>> }
>
>
> Currently no, sorry.
Thanks Nick, that save for looking any further.
As a workaround I discovered the XML output of valgrind.
That let me do funky filter things like:
<xsl:transform
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0"
>
<xsl:strip-space elements="*" />
<xsl:output method="xml" indent="yes"/>
<!-- match any occurence of RootOfAllEvil -->
<xsl:template match="error[.//fn='RootOfAllEvil']">
<!-- and filter out this kind for RootOfAllEvil -->
<xsl:choose>
<xsl:when test=".//kind[1]='Leak_StillReachable'"/>
<xsl:when test=".//kind[1]='Leak_IndirectlyLost'"/>
<xsl:otherwise>
<xsl:copy-of select="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match="error">
<xsl:copy-of select="."/>
</xsl:template>
<xsl:template match="*">
<xsl:apply-templates select="error"/>
</xsl:template>
</xsl:transform>
--
Cees Wesseling
PCRaster Environmental Software
|
|
From: Christian P. <tr...@ge...> - 2006-01-25 12:59:38
|
On Tuesday 24 January 2006 19:05, Dennis Lubert wrote: > >It is not unknown for people to port apps to Linux just so they > >can use Valgrind on them. =A0That's another possibility. > > Porting VC++ 6.0 code to linux could be a bigger problem though, > since it is known to horribly fail to comply to the iso c++ standard, > as an example it does not following scoping rules for for-loops and > has differente template syntax. best time to revalidate the sources and make it compliant though ;-) |
|
From: Christian P. <tr...@ge...> - 2006-01-25 12:59:04
|
On Wednesday 25 January 2006 10:17, KevinGPO wrote: > That's why I should upgrade to use MS Toolkit 2003 right? > > Anyway, my program is like... millions of lines long and is massive. It > usually takes 30 minutes to compile. 30 minutes to compile are certainly not "millions of lines" in fact, MSVC i= s=20 slow and not that fast. we're having here code with around 35,000 lines that takes (statically link= ed)=20 on MSVC (VS.NET 2005) about 20+ minutes to compile, mostly because it's=20 making heavy use of templates though. Regards, Christian Parpart. |
|
From: Nicholas N. <nj...@cs...> - 2006-01-25 11:07:52
|
On Wed, 25 Jan 2006, Cees wrote:
> But is there any way of definining something like?:
>
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:_Znwj
> ?? 1 or more of any functions
> fun:RootOfAllEvil
> }
Currently no, sorry.
Nick
|
|
From: Cees <ce...@pc...> - 2006-01-25 10:50:36
|
Hi,
I am trying to write suppression rules for leaks that originate from some
function say RootOfAllEvil.
Below that function there are many leaks but not all at the same stack depth.
AFAIK, I could suppress all _Znwj (C++ new) at depth 1 by doing:
{
<insert a suppression name here>
Memcheck:Leak
fun:_Znwj
fun:*
fun:RootOfAllEvil
}
and add more for depth 2,3, etc.
But is there any way of definining something like?:
{
<insert a suppression name here>
Memcheck:Leak
fun:_Znwj
?? 1 or more of any functions
fun:RootOfAllEvil
}
It sounds so naturraly to me that this is possible, but I am unable to find
information on if this is possible, or that I can achieve the same in another
fashion.
Tanks in advance,
Cees
|
|
From: KevinGPO <kev...@ho...> - 2006-01-25 09:16:32
|
That's why I should upgrade to use MS Toolkit 2003 right? Anyway, my program is like... millions of lines long and is massive. It usually takes 30 minutes to compile. "Dennis Lubert" <pla...@in...> wrote in message news:7.0...@pl...... > At 18:57 24.01.2006, Julian Seward wrote: > >>A research-grade problem, imo. >> >>It is not unknown for people to port apps to Linux just so they >>can use Valgrind on them. That's another possibility. > > Porting VC++ 6.0 code to linux could be a bigger problem though, since it > is known to horribly fail to comply to the iso c++ standard, as an example > it does not following scoping rules for for-loops and has differente > template syntax. > > greets > > Dennis > > > Carpe quod tibi datum est > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 |