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: Nicholas N. <nj...@cs...> - 2006-01-31 20:46:31
|
On Tue, 31 Jan 2006, Dirk Mueller wrote: >>> Any way I can make VG to give errors on all writes outside of allocated >>> by mallocs arear? >> No. > > Why not? the problem here is that it happens to hit a memory page that is > mapped as writeable (global offset table?). One possible workaround for this > would be to add big red zones around the heap area (32 MB or something like > that) and then we'd be able to catch writes there. Doesn't sound too > complicated, does it? It'll catch a small number, but it won't solve the general case. You needs bounds-checking for that. Or using DieHard's approach (http://www.cs.umass.edu/~emery/diehard/) will get you partway there, but I don't think that approach is a good one to use in Valgrind. Nick |
|
From: Dirk M. <dm...@gm...> - 2006-01-31 12:04:05
|
On Tuesday 31 January 2006 12:06, Nicholas Nethercote wrote: > > Any way I can make VG to give errors on all writes outside of allocated > > by mallocs arear? > No. Why not? the problem here is that it happens to hit a memory page that is mapped as writeable (global offset table?). One possible workaround for this would be to add big red zones around the heap area (32 MB or something like that) and then we'd be able to catch writes there. Doesn't sound too complicated, does it? Dirk |
|
From: Jorrit T. <jor...@gm...> - 2006-01-31 11:16:40
|
On 1/31/06, Nicholas Nethercote <nj...@cs...> wrote: > On Mon, 30 Jan 2006, Yuri wrote: > > > Seems like valgrind should be finding such things but it doesn't. > > Life is tough sometimes, yes? > > > Any way I can make VG to give errors on all writes outside of allocated > > by mallocs arear? > > No. > Perhaps it would be nice to have an option to increase the block red zones or something. Not sure if that is possible or easy to do. Greetings, -- 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: Nicholas N. <nj...@cs...> - 2006-01-31 11:06:56
|
On Mon, 30 Jan 2006, Yuri wrote: > Seems like valgrind should be finding such things but it doesn't. Life is tough sometimes, yes? > Any way I can make VG to give errors on all writes outside of allocated > by mallocs arear? No. Nick |
|
From: Ashley P. <as...@qu...> - 2006-01-31 09:46:57
|
On Mon, 2006-01-30 at 18:21 +0000, Julian Seward wrote:
> On Monday 30 January 2006 17:01, Ashley Pittman wrote:
> > On Sun, 2006-01-29 at 20:54 +0000, Julian Seward wrote:
> > > But VALGRIND_MAGIC_SEQUENCE is a low-level macro used as a building
> > > block for the higher client-request macros that users should be using.
> > > So I don't thing there should be a problem. In any case I sure hope
> > > not since I recently renamed it to VALGRIND_DO_CLIENT_REQUEST as that's
> > > a more sensible name for it.
> >
> > That might explain a few things, I took a private copy of
> > memcheck.h/valgrind.h a few weeks ago (on the 17th Jan IIRC) and just
> > found today that they no longer work with valgrind from SVN.
>
> Oops, sorry about that. It didn't even occur to me I'd be breaking
> other people's code. Perhaps we should say, on each macro, whether
> they are suitable for end-user use or not.
It seems a bit more fundamental than that, even RUNNING_ON_VALGRIND has
broken, code compiled with the old headers always returns 0.
valgrind.h and memcheck.h already contain documentation on what to call
and what not to call from end-user code, basically anything except one
memcheck entry.
/* This is just for memcheck's internal use - don't use it */
_VG_USERREQ__MEMCHECK_RECORD_OVERLAP_ERROR
= VG_USERREQ_TOOL_BASE('M','C') + 256
Whilst we are on the subject I've noticed that when I include valgrind.h
in results in two extra symbols being exported, VALGRIND_PRINTF and
VALGRIND_PRINTF_BACKTRACE. This probably isn't a problem as they are
weak symbols but there is no explanation of what they do or how I might
use them.
Ashley,
|
|
From: Paul P. <ppl...@gm...> - 2006-01-31 05:41:58
|
On 1/30/06, Yuri <yu...@ra...> wrote:
> I tried to catch the prob lem in the simple testcase and VG says it's no =
problem.
> Why wouldn't it find such simple issue?
Most likely because 'pi[-100]' falls into .data section for the
executable, and it is perfectly legal to write there.
> main() {
> int *pi =3D new int;
> pi[-100] =3D 1;
> delete pi;
> }
FWIW, here is what Insure++ from www.parasoft.com reports:
[test.c:3] **WRITE_BAD_INDEX**
>> pi[-100] =3D 1;
Writing array out of range: pi[-100]
Index used : -100
In block : 0x0000000000503060 thru 0x0000000000503063 (4 bytes)
pi, allocated at test.c, 2
malloc() (interface)
operator new()
main() test.c, 2
Stack trace where the error occurred:
main() test.c, 3
**Memory corrupted. Program may crash!!**
Cheers,
|
|
From: Yuri <yu...@ra...> - 2006-01-31 00:42:33
|
I have the issue that my program seems to corrupt memory allocation internal
structures.
Thery might be outside the red zones but still.
Seems like valgrind should be finding such things but it doesn't.
Any way I can make VG to give errors on all writes outside of allocated
by mallocs arear?
Yuri
Quoting Julian Seward <js...@ac...>:
> On Tuesday 31 January 2006 00:23, Yuri wrote:
> > I tried to catch the prob lem in the simple testcase and VG says it's no
> > problem.
> >
> > Why wouldn't it find such simple issue?
> >
> > I use valgrind-3.0.1 on amd64 platform.
> >
> > Thanx,
> > Yuri
> >
> >
> > ---- testcase -----
> > main() {
> > int *pi = new int;
> > pi[-100] = 1;
> > delete pi;
> > }
>
> It can only catch probably pi[-1] .. pi[-4] and
> pi[100] .. pi[103], since the block red-zones are 16-bytes long.
> At least if I remember right they are.
>
> J
>
>
> -------------------------------------------------------
> 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: Julian S. <js...@ac...> - 2006-01-31 00:36:32
|
On Tuesday 31 January 2006 00:23, Yuri wrote:
> I tried to catch the prob lem in the simple testcase and VG says it's no
> problem.
>
> Why wouldn't it find such simple issue?
>
> I use valgrind-3.0.1 on amd64 platform.
>
> Thanx,
> Yuri
>
>
> ---- testcase -----
> main() {
> int *pi = new int;
> pi[-100] = 1;
> delete pi;
> }
It can only catch probably pi[-1] .. pi[-4] and
pi[100] .. pi[103], since the block red-zones are 16-bytes long.
At least if I remember right they are.
J
|
|
From: Yuri <yu...@ra...> - 2006-01-31 00:24:02
|
I tried to catch the prob lem in the simple testcase and VG says it's no problem.
Why wouldn't it find such simple issue?
I use valgrind-3.0.1 on amd64 platform.
Thanx,
Yuri
---- testcase -----
main() {
int *pi = new int;
pi[-100] = 1;
delete pi;
}
|