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
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Lee K. <lki...@cs...> - 2003-08-05 08:51:59
|
Just a little snippet of useless info - going back through the archives I have of this list the average clock rate is 1448 MHz. L. Lee Kindness writes: > > > GPL'd, by Julian Seward. ==26211== Estimated CPU clock rate is 699 MHz |
|
From: Lee K. <lki...@cs...> - 2003-08-05 08:40:10
|
I don't know, but you seem to be missing smething here... Valgrind
already IS telling you there is something wrong with your program. It
then says "fair enough" and lets your program dig its own grave. What
would you want it do instead?
1. Return some value instead of referencing the memory? What value?
Your program after this state will be calculating based on an
incorrect value.
2. Simply skip the instruction?!
3. Abort execution?
Do you know what the proper way is?
4. Fix your program - it's got no chance of working as-is! YOU should
be checking for NULL parameters in your code if they are possible in
the calling chain.
L/
Bor...@pd... writes:
> I think a correct behaviour would be something to ask the user if he=
wants
> to get a core, wants to end the program, or continue with the execut=
ion
> beside the printing of the errortext together with a the stack outpu=
t.=20
> The way valgrind handles this situation now, seems like a not well d=
efined
> behaviour of valgrind in itself. With the above mentioned method, th=
e user
> would be sure, that this is a bug of his program and not one of
> valgrind...which is really usefull, when the scenario for the Null-P=
ointer
> Access gets much more complicated than my little example programm. F=
or
> example by passing of an NULL pointer as function parameter through =
some
> function calls. If you than only get a core for valgrind, I don't th=
ink
> every user will see the bug.
>=20
> Sincerely Borg Enders
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Nicholas Nethercote [mailto:nj...@ca...]=20
> Gesendet: Dienstag, 5. August 2003 10:08
> An: Enders, Borg
> Cc: val...@li...
> Betreff: Re: [Valgrind-users] core for null pointer access
>=20
>=20
> On Tue, 5 Aug 2003 Bor...@pd... wrote:
>=20
> > The following programm causes a core:
> > int main( int argc, char** argv )
> > {
> > int *a =3D NULL;
> >
> > int b =3D *a;
> >
> > return 0;
> > }
> >
> > Valgrind output:
> > =3D=3D26211=3D=3D Memcheck, a.k.a. Valgrind, a memory error detect=
or for=20
> > x86-linux. =3D=3D26211=3D=3D Copyright (C) 2002-2003, and GNU GPL'=
d, by Julian=20
> > Seward. =3D=3D26211=3D=3D Using valgrind-20030725, a program super=
vision=20
> > framework for x86-linux. =3D=3D26211=3D=3D Copyright (C) 2000-2003=
, and GNU=20
> > GPL'd, by Julian Seward. =3D=3D26211=3D=3D Estimated CPU clock rat=
e is 699 MHz
> > =3D=3D26211=3D=3D For more details, rerun with: -v
> > =3D=3D26211=3D=3D
> > =3D=3D26211=3D=3D Invalid read of size 4
> > =3D=3D26211=3D=3D at 0x804844A: main (speicher_test.cc:23)
> > =3D=3D26211=3D=3D by 0x8048340: (within /home/benders/val2/tst/=
a.out)
> > =3D=3D26211=3D=3D Address 0x0 is not stack'd, malloc'd or free'=
d
> > Memory fault(coredump)
> >
> >
> > I think valgrind, should handle this problem correctly and not cor=
e by=20
> > it's self.
>=20
> Really? What do you think would be the right way to handle this pro=
blem
> correctly?
>=20
> N
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites includi=
ng
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_07230=
3_01/01
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: <Bor...@pd...> - 2003-08-05 08:18:16
|
I think a correct behaviour would be something to ask the user if he =
wants
to get a core, wants to end the program, or continue with the execution
beside the printing of the errortext together with a the stack output.=20
The way valgrind handles this situation now, seems like a not well =
defined
behaviour of valgrind in itself. With the above mentioned method, the =
user
would be sure, that this is a bug of his program and not one of
valgrind...which is really usefull, when the scenario for the =
Null-Pointer
Access gets much more complicated than my little example programm. For
example by passing of an NULL pointer as function parameter through =
some
function calls. If you than only get a core for valgrind, I don't think
every user will see the bug.
Sincerely Borg Enders
-----Urspr=FCngliche Nachricht-----
Von: Nicholas Nethercote [mailto:nj...@ca...]=20
Gesendet: Dienstag, 5. August 2003 10:08
An: Enders, Borg
Cc: val...@li...
Betreff: Re: [Valgrind-users] core for null pointer access
On Tue, 5 Aug 2003 Bor...@pd... wrote:
> The following programm causes a core:
> int main( int argc, char** argv )
> {
> int *a =3D NULL;
>
> int b =3D *a;
>
> return 0;
> }
>
> Valgrind output:
> =3D=3D26211=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector =
for=20
> x86-linux. =3D=3D26211=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, =
by Julian=20
> Seward. =3D=3D26211=3D=3D Using valgrind-20030725, a program =
supervision=20
> framework for x86-linux. =3D=3D26211=3D=3D Copyright (C) 2000-2003, =
and GNU=20
> GPL'd, by Julian Seward. =3D=3D26211=3D=3D Estimated CPU clock rate =
is 699 MHz
> =3D=3D26211=3D=3D For more details, rerun with: -v
> =3D=3D26211=3D=3D
> =3D=3D26211=3D=3D Invalid read of size 4
> =3D=3D26211=3D=3D at 0x804844A: main (speicher_test.cc:23)
> =3D=3D26211=3D=3D by 0x8048340: (within =
/home/benders/val2/tst/a.out)
> =3D=3D26211=3D=3D Address 0x0 is not stack'd, malloc'd or free'd
> Memory fault(coredump)
>
>
> I think valgrind, should handle this problem correctly and not core =
by=20
> it's self.
Really? What do you think would be the right way to handle this =
problem
correctly?
N
|
|
From: Tom H. <th...@cy...> - 2003-08-05 08:10:17
|
In message <E8C...@fs...>
Borg Enders <Bor...@pd...> wrote:
> I think valgrind, should handle this problem correctly and not core
> by it's self.
But valgrind didn't core, your program did. You read invalid
memory by reading through a null pointer. Valgrind warned you
what your program was about to do, then your program did it
and suffered the consequences.
To be honest I'm not quite sure what you are suggesting - that
valgrind should fake up any read that it thinks is questionable
and return some dummy value?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 08:07:47
|
On Tue, 5 Aug 2003 Bor...@pd... wrote:
> The following programm causes a core:
> int main( int argc, char** argv )
> {
> int *a = NULL;
>
> int b = *a;
>
> return 0;
> }
>
> Valgrind output:
> ==26211== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==26211== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==26211== Using valgrind-20030725, a program supervision framework for
> x86-linux.
> ==26211== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
> ==26211== Estimated CPU clock rate is 699 MHz
> ==26211== For more details, rerun with: -v
> ==26211==
> ==26211== Invalid read of size 4
> ==26211== at 0x804844A: main (speicher_test.cc:23)
> ==26211== by 0x8048340: (within /home/benders/val2/tst/a.out)
> ==26211== Address 0x0 is not stack'd, malloc'd or free'd
> Memory fault(coredump)
>
>
> I think valgrind, should handle this problem correctly and not core by it's
> self.
Really? What do you think would be the right way to handle this problem
correctly?
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 07:34:38
|
On Tue, 5 Aug 2003, Andy Bell wrote:
> But I'm having problems suppressing some errors (version 20030725).
First rule of suppression writing: use --gen-suppressions=yes. Then
tweak its output if necessary.
> ==5968== Syscall param writev(vector[...]) contains uninitialised or
> unaddressable byte(s)
> ==5968== at 0x40188467: vgAllRoadsLeadToRome_writev (vg_intercept.c:116)
> ==5968== by 0x401884A8: __writev (vg_intercept.c:732)
> ==5968== by 0x4045AB45: (within /usr/X11R6/lib/libX11.so.6.2)
> ==5968== by 0x4045B656: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
> ==5968== by 0x4043F7F1: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
> ==5968== by 0x40427B1E: XListFonts (in /usr/X11R6/lib/libX11.so.6.2)
>
> I think this rule from the default suppressions file should fix it, but
> it doesn't:
>
> {
> writev(vector[...])/__writev/libX11.so.6.2/libX11.so.6.2
> Addrcheck,Memcheck:Param
> writev(vector[...])
> fun:__writev
> obj:/usr/X11R6/lib/libX11.so.6.2
> obj:/usr/X11R6/lib/libX11.so.6.2
> }
You need to include all the functions/object files in the stack trace, in
order, something like this:
{
writev(vector[...])/__writev/libX11.so.6.2/libX11.so.6.2
Addrcheck,Memcheck:Param
writev(vector[...])
fun:vgAllRoadsLeadToRome_writev
fun:__writev
obj:/usr/X11R6/lib/libX11.so.6.2
fun:_X11TransWritev
}
> I've tried the following and various other permutations:
>
> {
> SSL_shit/*
> Addrcheck,Memcheck:Addr4
> fun:RSA_verify
> fun:BN_bin2bn
> fun:BN_num_bits
> fun:BN_mod_exp_mont
> fun:des_set_key_unchecked
> fun:des_encrypt2
> }
The list of functions in a suppression must match a stack trace. I think
you're trying to match multiple stack traces with a single suppression
here. You need multiple suppressions.
Again, use --gen-suppressions=yes. It makes things much easier.
N
|
|
From: <Bor...@pd...> - 2003-08-05 07:25:07
|
Hello everybody,
The following programm causes a core:
int main( int argc, char** argv )
{
int *a = NULL;
int b = *a;
return 0;
}
Valgrind output:
==26211== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==26211== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==26211== Using valgrind-20030725, a program supervision framework for
x86-linux.
==26211== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==26211== Estimated CPU clock rate is 699 MHz
==26211== For more details, rerun with: -v
==26211==
==26211== Invalid read of size 4
==26211== at 0x804844A: main (speicher_test.cc:23)
==26211== by 0x8048340: (within /home/benders/val2/tst/a.out)
==26211== Address 0x0 is not stack'd, malloc'd or free'd
Memory fault(coredump)
I think valgrind, should handle this problem correctly and not core by it's
self.
sincerely Borg Enders
|
|
From: Andy B. <an...@em...> - 2003-08-05 04:31:02
|
Here's another valgrind fan. I've been weeding lots of bugs from my
application with its help.
But I'm having problems suppressing some errors (version 20030725).
First, I always get this one:
==5968== Syscall param writev(vector[...]) contains uninitialised or
unaddressable byte(s)
==5968== at 0x40188467: vgAllRoadsLeadToRome_writev (vg_intercept.c:116)
==5968== by 0x401884A8: __writev (vg_intercept.c:732)
==5968== by 0x4045AB45: (within /usr/X11R6/lib/libX11.so.6.2)
==5968== by 0x4045B656: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
==5968== by 0x4043F7F1: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
==5968== by 0x40427B1E: XListFonts (in /usr/X11R6/lib/libX11.so.6.2)
I think this rule from the default suppressions file should fix it, but
it doesn't:
{
writev(vector[...])/__writev/libX11.so.6.2/libX11.so.6.2
Addrcheck,Memcheck:Param
writev(vector[...])
fun:__writev
obj:/usr/X11R6/lib/libX11.so.6.2
obj:/usr/X11R6/lib/libX11.so.6.2
}
Second, my app uses OpenSSL (version 0.9.6i), statically linked. For the
life of me I can't get rid of the reams of errors that valgrind reports:
==5968== Thread 3:
==5968== Syscall param write(buf) contains uninitialised or
unaddressable byte(s)
==5968== at 0x420DACE4: __libc_write (in /lib/i686/libc-2.2.5.so)
==5968== by 0x81AAEE5: sock_write (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968== Address 0x43A1B6A6 is 98 bytes inside a block of size 21848
alloc'd
==5968== at 0x40027894: malloc (vg_replace_malloc.c:153)
==5968== by 0x8195579: CRYPTO_malloc (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Conditional jump or move depends on uninitialised value(s)
==5968== at 0x819CEAD: RSA_verify (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Conditional jump or move depends on uninitialised value(s)
==5968== at 0x819B6EB: BN_bin2bn (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Use of uninitialised value of size 4
==5968== at 0x819B8CD: BN_num_bits (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Conditional jump or move depends on uninitialised value(s)
==5968== at 0x81CE704: BN_mod_exp_mont (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Use of uninitialised value of size 4
==5968== at 0x8198793: des_set_key_unchecked (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
==5968== Thread 3:
==5968== Use of uninitialised value of size 4
==5968== at 0x8199C64: des_encrypt2 (in
/home/andy/EmLinuxPCX/Application/EmBrowser/bin-x86/dino)
==5968==
(Repeat offences removed for more brevity.)
I've tried the following and various other permutations:
{
SSL_shit/*
Addrcheck,Memcheck:Addr4
fun:RSA_verify
fun:BN_bin2bn
fun:BN_num_bits
fun:BN_mod_exp_mont
fun:des_set_key_unchecked
fun:des_encrypt2
}
{
SSL_shit2/*
Memcheck:Cond
fun:RSA_verify
fun:BN_bin2bn
fun:BN_num_bits
fun:BN_mod_exp_mont
fun:des_set_key_unchecked
fun:des_encrypt2
}
Here's the output on startup:
==5968== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==5968== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==5968== Using valgrind-20030725, a program supervision framework for
x86-linux.
==5968== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==5968==
==5968== My PID = 5968, parent PID = 23579. Prog and args are:
==5968== dino
==5968==
==5968== Startup, with flags:
==5968== --suppressions=/usr/local/lib/valgrind/default.supp
==5968== --suppressions=dino.supp
==5968== --num-callers=40
==5968== --error-limit=no
==5968== --logfile=valgrind.out
==5968== -v
...
==5968== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==5968== Reading suppressions file: dino.supp
Any insights would be much appreciated.
Cheers,
Andy Bell
|