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: Nicholas N. <nj...@ca...> - 2003-08-05 10:29:43
|
On Tue, 5 Aug 2003, Vincent Penquerc'h wrote:
> > Till now I'am only disappointed by one point about valgrind, and that
> > is the lack of monitoring of local memory within function call.
> > Especially detects it no under or over runs for arrays.
>
> Yes, that could be fixed by adding non addressable "padding"
> bytes before and after an array, I guess. Though I'm not sure
> if Valgrind could detect the creation of such an array from
> the instructions though. And it would definitely not be able
> to do so if there are more than one arrays that are merged
> together in their creation (which is just a manipulation of
> the stack pointer).
It's extremely difficult to do anything useful just by watching the stack
pointer. GCC generates code in such a way that %esp jumps all over the
place, leaving holes in the stack that aren't used, things like that. I
think the only way you can get anything sensible about the structure of
the stack is to use debug information, without it, you just can't tell
where stack arrays/variables start and end. (Static arrays are similarly
difficult. Heap-allocated arrays are trivial by comparison.)
Similarly, you can't even tell for sure when you've entered a function
just by watching the dynamic instruction stream; a 'call' instruction is
a good sign, but there are other, weirder ways of entering a function,
like jumps (used by dynamically linked libraries a lot) and things like
pushing a functions start address and doing 'ret', and other horrible
things. The best way, AFAIK, is to rely on the symbol information.
On Tue, 5 Aug 2003, Erik Corry wrote:
> > Well, the array overruns not detected by Valgrind will never cause a seg
> > fault.
>
> Not true:
>
> void f()
> {
> char a[4];
> int *b;
> int c;
> b = &c;
> a[5] = 123;
> *b = 456;
> }
>
> valgrind will tell you that the write through b is a problem,
> but the real reason is the array overrun which valgrind cannot
> detect, but which (indirectly) causes an array overrun.
I just tried it, without problems, but that's probably due to GCC adding
random padding between 'a' and 'b'.
You're right, I should have been more precise: if you get a seg fault due
to an array overrun, Valgrind will always give you some related error
message before the seg fault happens. Any objections to that statement? :)
N
|
|
From: Erik C. <er...@ar...> - 2003-08-05 10:22:53
|
On Tue, Aug 05, 2003 at 11:02:03AM +0100, Nicholas Nethercote wrote:
>
> > Especially the second leads to a really bad behaviour by dumping your
> > memory.
>
> Well, the array overruns not detected by Valgrind will never cause a seg
> fault.
Not true:
void f()
{
char a[4];
int *b;
int c;
b = &c;
a[5] = 123;
*b = 456;
}
valgrind will tell you that the write through b is a problem,
but the real reason is the array overrun which valgrind cannot
detect, but which (indirectly) causes an array overrun.
I don't think there's any way to fix this in valgrind. Perhaps
this: http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ is what the
original poster wants. Or perhaps Java is what he really wants.
--
Erik Corry er...@ar...
|
|
From: Josef W. <Jos...@gm...> - 2003-08-05 10:14:07
|
Hi, On Tuesday 05 August 2003 11:23, Nicholas Nethercote wrote: > On Tue, 5 Aug 2003 Bor...@pd... wrote: > > 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 > [...] > There's an element of trust involved with using any programming tool. For > example, if your program is behaving unexpectedly, do you suspect your > program, or the compiler? It's a similar issue here -- at a certain > level, you have to trust the tool you are using. I'm not so sure about this. If requested, a tool should provide as much details as possible to allow the user to check for himself if the error is in the tool or his own program. And this *is* difficult to do. In the case of a faulting compiler, the user can have a look at the disassembled code with GDB; he even can single step assembler. IMHO, that's one crucial point with using a debugger. I recently introduced an annotated assembler view into KCachegrind and added an option to calltree to dump cost per instruction. Before this, I *had* to trust my tool for correct summation per source line. Now I actually can check for correctness, as with annotated assembler, event counts (instruction fetches, cache misses) are much more understandable. Another example: I skip PLT sections in call chains, without giving feedback to the user. This is *bad*, I will have to change it: Nobody will understand from dissassembled code, why a CALL leads to 2 calls to unrelated positions. Back to Valgrind: Valgrind's SEGFAULT handler should give out a precise error message after a SEGFAULT is catched, that this was because of application code. Obviously, Valgrind already contains such a message when the SEGFAULT appears in Valgrind code. The addition should be easy. Perhaps there should be an option to give out a chunk of dissassembled code within Valgrinds error message, together with a dump of register content? This would allow the user to check if the dissassembled code really was able to raise e.g. an SEGFAULT. > Why should you trust it? Well, if lots of other people use it, that's a > good sign. Also, if you use the tool yourself for a while, you'll soon > get a feel for how trustworthy it is. Hmmm... Josef |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-05 10:02:45
|
> Till now I'am only disappointed by one point about valgrind, > and that is the > lack of monitoring of local memory within function call. > Especially detects > it no under or over runs for arrays. Yes, that could be fixed by adding non addressable "padding" bytes before and after an array, I guess. Though I'm not sure if Valgrind could detect the creation of such an array from the instructions though. And it would definitely not be able to do so if there are more than one arrays that are merged together in their creation (which is just a manipulation of the stack pointer). For this kind of things, I believe there exist some patches to GCC to detect stack smashing (extra code being emitted to check for the return address to be left unchanged between a function being entered and it being left). I can't be more specific now, I've never actually had a look, just heard of it. Google may help on this one. -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 10:02:07
|
On Tue, 5 Aug 2003 Bor...@pd... wrote:
> I've just started to use valgrind. But my philosophy on every program is,
> it's better to tell the user what's the problem if you can, then to let him
> guess where the problem lies.
> I think it would be a really usefull feature for a lot of users, if you
> could write a short message,
> When you know that the programm will write a core.
> By supervising the memory you should know when some program tries to
> dereference a NULL-Pointer.
As I said, Valgrind does tell you this:
==8495== Invalid read of size 4
==8495== at 0x804830E: main (core.c:5)
==8495== by 0x8048264: ??? (start.S:81)
==8495== Address 0x0 is not stack'd, malloc'd or free'd
Segmentation fault (core dumped)
I think your suggested message and prompt would get annoying quite
quickly; it's just repeating information. Also, Vincent made a good
point about programs for which an interactive prompt is unsuitable.
> Till now I'am only disappointed by one point about valgrind, and that is the
> lack of monitoring of local memory within function call. Especially detects
> it no under or over runs for arrays.
>
> For Example take the following program:
> #include <stdio.h>
>
> int main( int argc, char** argv )
> {
>
> int test[3];
> test[4] = 42; // out of bounds write
> printf("%d\n", test[4] );
Yes, this is an array overrun.
> char* x = "test";
> x[5] = 'x'; // the same as above
> printf("%s\n", x ); // causes memory dump
It's actually the assignment to x[5] that cause the seg fault. Run your
core file through gdb to see. The reason is that you're writing to
read-only memory. There was a thread on this mailing list about this just
the other day called "detect writing to TOC(?)". The (well, my)
conclusion was that, yes, writing to read-only memory can cause seg
faults, but they're rare and detecting them would have a big performance
cost, so it's not worth it. AFAIK, writing to read-only memory is the
only way a program can seg fault without Valgrind giving a warning first.
> return 0;
> }
>
>
> I think this are really common bugs, which would be really usefull to
> detect.
You're absolutely right, and if anyone knows how to do it without access
to the program's source code, with reasonable performance, and without
horrific complexity, we'd love to know :)
> Especially the second leads to a really bad behaviour by dumping your
> memory.
Well, the array overruns not detected by Valgrind will never cause a seg
fault. As I said, the dump for the program above is caused by writing to
read-only memory.
N
|
|
From: <Bor...@pd...> - 2003-08-05 09:42:27
|
I've just started to use valgrind. But my philosophy on every program =
is,
it's better to tell the user what's the problem if you can, then to let =
him
guess where the problem lies.
I think it would be a really usefull feature for a lot of users, if you
could write a short message,
When you know that the programm will write a core.=20
By supervising the memory you should know when some program tries to
dereference a NULL-Pointer.
Till now I'am only disappointed by one point about valgrind, and that =
is the
lack of monitoring of local memory within function call. Especially =
detects
it no under or over runs for arrays.
For Example take the following program:
#include <stdio.h>=20
int main( int argc, char** argv )=20
{=20
int test[3];=20
test[4] =3D 42; // out of bounds write=20
printf("%d\n", test[4] );=20
char* x =3D "test";=20
x[5] =3D 'x'; // the same as above=20
printf("%s\n", x ); // causes memory dump=20
return 0;=20
}=20
I think this are really common bugs, which would be really usefull to
detect.
Especially the second leads to a really bad behaviour by dumping your
memory.
-----Urspr=FCngliche Nachricht-----
Von: Nicholas Nethercote [mailto:nj...@ca...]=20
Gesendet: Dienstag, 5. August 2003 11:23
An: Enders, Borg
Cc: val...@li...
Betreff: Re: AW: [Valgrind-users] core for null pointer access
On Tue, 5 Aug 2003 Bor...@pd... wrote:
> 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
Ok, this is a reasonable point.
Have you used Valgrind much? Have you found this to be problem -- not =
being
sure whether a seg fault is caused by your program or by a bug in =
Valgrind?
Or are you new to Valgrind, and you think it might be a problem?
There's an element of trust involved with using any programming tool. =
For
example, if your program is behaving unexpectedly, do you suspect your
program, or the compiler? It's a similar issue here -- at a certain =
level,
you have to trust the tool you are using.
Why should you trust it? Well, if lots of other people use it, that's =
a
good sign. Also, if you use the tool yourself for a while, you'll soon =
get
a feel for how trustworthy it is.
> My point is: an "Invalid read" followed by a core makes it not always =
> clear if this is a bug of valgrind or the tested programm. A short=20
> message to the user before the core is written would make this=20
> situation more clear.
I would consider the "Invalid read" message to be exactly this "message =
to
the user".
> 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? =
Continue=20
> on own risk [r/R]?'
Valgrind can't know ahead of time whether an invalid read is actually =
going
to cause a seg fault. Unless its a blatantly bad access, eg. to 0x0, =
in
which case the "Invalid read" hopefully makes it pretty clear what the
problem is. And with a blatantly bad access, continuing at your own =
risk is
the same as writing core straight away. And stopping execution without
producing a core file... well, that doesn't seem much more useful. =
Unless
your program installs a SIGSEGV handler, that will complicate matters.
Valgrind certainly has bugs, but from my experience it is clear when a =
bug
is caused by Valgrind. For example, Valgrind has a SIGSEGV handler or
something like that, so that on the rare occasions it seg faults =
itself, you
get a message like "seg fault within Valgrind itself". Perhaps other =
people
have different experiences.
Also, if your program seg faults normally, and also seg faults under
Valgrind, then that seems pretty clear. Sometimes your program might =
seg
fault under Valgrind and not normally, or vice versa, due to the fact =
that
memory gets laid out in a different way. But Valgrind's error messages
should make things clear.
> I really think valgrind is as great a memory checker as there is for=20
> free to get, but it needs on some Edges a little bit more work. I'am=20
> working in a medium sized firm, and have installed valgrind for all =
of=20
> our programmers, but some of them would always seek the fault by=20
> someone else, before thinking that they could have made a fault...
Again, I think it's a matter of trust. If a programmer is sceptical, =
are
they going be more convinced by a message that says "error in your =
program,
really, I promise" rather than just "error in your program"? If your =
error
message above was used, why would a sceptic believe that any more than =
any
other error message? It too might be a bug in Valgrind (I don't think =
it
would, but a sceptic might).
> If you than only get a core for valgrind, I don't think every user=20
> will see the bug.
Sorry, I don't understand this. Do you mean cases where the program =
dumps
core when running under Valgrind, but does not when running normally?
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 09:23:23
|
On Tue, 5 Aug 2003 Bor...@pd... wrote: > 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 Ok, this is a reasonable point. Have you used Valgrind much? Have you found this to be problem -- not being sure whether a seg fault is caused by your program or by a bug in Valgrind? Or are you new to Valgrind, and you think it might be a problem? There's an element of trust involved with using any programming tool. For example, if your program is behaving unexpectedly, do you suspect your program, or the compiler? It's a similar issue here -- at a certain level, you have to trust the tool you are using. Why should you trust it? Well, if lots of other people use it, that's a good sign. Also, if you use the tool yourself for a while, you'll soon get a feel for how trustworthy it is. > My point is: an "Invalid read" followed by a core makes it not always > clear if this is a bug of valgrind or the tested programm. A short > message to the user before the core is written would make this situation > more clear. I would consider the "Invalid read" message to be exactly this "message to the user". > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? Continue > on own risk [r/R]?' Valgrind can't know ahead of time whether an invalid read is actually going to cause a seg fault. Unless its a blatantly bad access, eg. to 0x0, in which case the "Invalid read" hopefully makes it pretty clear what the problem is. And with a blatantly bad access, continuing at your own risk is the same as writing core straight away. And stopping execution without producing a core file... well, that doesn't seem much more useful. Unless your program installs a SIGSEGV handler, that will complicate matters. Valgrind certainly has bugs, but from my experience it is clear when a bug is caused by Valgrind. For example, Valgrind has a SIGSEGV handler or something like that, so that on the rare occasions it seg faults itself, you get a message like "seg fault within Valgrind itself". Perhaps other people have different experiences. Also, if your program seg faults normally, and also seg faults under Valgrind, then that seems pretty clear. Sometimes your program might seg fault under Valgrind and not normally, or vice versa, due to the fact that memory gets laid out in a different way. But Valgrind's error messages should make things clear. > I really think valgrind is as great a memory checker as there is for > free to get, but it needs on some Edges a little bit more work. I'am > working in a medium sized firm, and have installed valgrind for all of > our programmers, but some of them would always seek the fault by > someone else, before thinking that they could have made a fault... Again, I think it's a matter of trust. If a programmer is sceptical, are they going be more convinced by a message that says "error in your program, really, I promise" rather than just "error in your program"? If your error message above was used, why would a sceptic believe that any more than any other error message? It too might be a bug in Valgrind (I don't think it would, but a sceptic might). > If you than only get a core for valgrind, I don't think every user will > see the bug. Sorry, I don't understand this. Do you mean cases where the program dumps core when running under Valgrind, but does not when running normally? N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-05 09:21:00
|
> I think like valgrind works now it's not a well defined > behavoiur (one term > you could know out of computer science), and all it should do is print > something like the following output: It seems to be it's well defined behavior. Valgrind's behaving correctly, and then your program crashes. If you wanted to have V somehow not allow your program to crash (eg, skipping the insn), then it would really be dodgy behavior, and IMHO not Valgrind's job, which is to execute your actual program, with checks. > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? > Continue on > own risk [r/R]?' Every program may not have a TTY. Or may have a TTY but no input. Or may run unattended. And may spew thousands of reports before the really interesting (crashing) one. etc. It could be done with an option though. > Even a simple message from valgrind like the following would make the > situation clear: > > 'Your program has caused a memory fault.' That's what it does, really. And the core is here to help you debug it. > My point is: an "Invalid read" followed by a core makes it > not always clear > if this is a bug of valgrind or the tested programm. A short > message to the > user before the core is written would make this situation more clear. If possible, then maybe. But I'm not sure V could catch every case of it. Catching signals etc may help, but this would not be very foolproof. -- Vincent Penquerc'h |
|
From: <Bor...@pd...> - 2003-08-05 09:07:38
|
And that's the point, in this case valgrind knows, that the access = after this invalid read will cause a Core dump, because you try to access a Null-Pointer and that it should = tell the user. I really think valgrind is as great a memory checker as there is for = free to get, but it needs on some=20 Edges a little bit more work. I'am working in a medium sized firm, and have installed valgrind for = all of our programmers, but some of them would always seek the fault by = someone else, before thinking that they could have made a fault... -----Urspr=FCngliche Nachricht----- Von: Lee Kindness [mailto:lki...@cs...]=20 Gesendet: Dienstag, 5. August 2003 11:02 An: Enders, Borg Cc: lki...@cs...; val...@li... Betreff: AW: [Valgrind-users] core for null pointer access Bor...@pd... writes: > Don't get personal. I'am checking for Null-Pointers in my code...all = I do > here is discuss a hypothetic case. I wasn't, but if your read it that way i'll apologise. > I think like valgrind works now it's not a well defined behavoiur = (one term > you could know out of computer science), and all it should do = is print > something like the following output: >=20 > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? = Continue on > own risk [r/R]?' >=20 > Even a simple message from valgrind like the following would make = the > situation clear: >=20 > 'Your program has caused a memory fault.'=20 >=20 > After such a message every user should know, that It's his bug and = not a > bug of valgrind. >=20 > So to sum up: > My point is: an "Invalid read" followed by a core makes it not = always clear > if this is a bug of valgrind or the tested programm. A short message to the > user before the core is written would make this = situation more > clear. But Valgrind doesn't know that an "Invalid read" will go on to produce = a core dump - many do not. I think a good position would be to assume the bugs are in your code?=20 L. |
|
From: Lee K. <lki...@cs...> - 2003-08-05 09:02:12
|
Bor...@pd... writes: > Don't get personal. I'am checking for Null-Pointers in my code...all I do > here is discuss a hypothetic case. I wasn't, but if your read it that way i'll apologise. > I think like valgrind works now it's not a well defined behavoiur (one term > you could know out of computer science), and all it should do is print > something like the following output: > > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? Continue on > own risk [r/R]?' > > Even a simple message from valgrind like the following would make the > situation clear: > > 'Your program has caused a memory fault.' > > After such a message every user should know, that It's his bug and not a > bug of valgrind. > > So to sum up: > My point is: an "Invalid read" followed by a core makes it not always clear > if this is a bug of valgrind or the tested programm. A short message to the > user before the core is written would make this situation more > clear. But Valgrind doesn't know that an "Invalid read" will go on to produce a core dump - many do not. I think a good position would be to assume the bugs are in your code? L. |
|
From: Joerg B. <jo...@we...> - 2003-08-05 09:01:04
|
Bor...@pd... wrote: > 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 if you are in doubt about a tools, try to use a different tool to do the same job. In this case, maybe you could led gdb verify that this is a bug in you application. Joerg |
|
From: <Bor...@pd...> - 2003-08-05 08:53:37
|
Don't get personal. I'am checking for Null-Pointers in my code...all I =
do
here is discuss a hypothetic case.
I think like valgrind works now it's not a well defined behavoiur (one =
term
you could know out of computer science), and all it should do is print
something like the following output:
'Null Pointer access: Write core [c/C]? Stop execution [s/S]? Continue =
on
own risk [r/R]?'
Even a simple message from valgrind like the following would make the
situation clear:
'Your program has caused a memory fault.'=20
After such a message every user should know, that It's his bug and not =
a
bug of valgrind.
So to sum up:
My point is: an "Invalid read" followed by a core makes it not always =
clear
if this is a bug of valgrind or the tested programm. A short message to =
the
user before the core is written would make this situation more clear.
-----Urspr=FCngliche Nachricht-----
Von: Lee Kindness [mailto:lki...@cs...]=20
Gesendet: Dienstag, 5. August 2003 10:40
An: Enders, Borg; val...@li...
Cc: Lee Kindness
Betreff: AW: [Valgrind-users] core for null pointer access
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
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. >=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 =
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.
>=20
> Really? What do you think would be the right way to handle this =
problem
> correctly? >=20
> N
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites =
including >
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_072303_01=
/01
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
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
|
|
From: Rich <rd...@lu...> - 2003-08-04 15:50:26
|
When I run my program directly it does not segfault. It immediately segfaults with valgrind-20030725 with libc 2.3.2. The same tests for libc 2.0 with valgrind 1.9.6 do not segfault. Any ideas on what's changed in glibc or valgrind? I've tried this with and without the option "--run-libc-freeres=no." valgrind --run-libc-freeres=no --leak-check=yes ./durendal ==24134== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==24134== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==24134== Using valgrind-20030725, a program supervision framework for x86-linux. ==24134== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==24134== Estimated CPU clock rate is 2397 MHz ==24134== For more details, rerun with: -v ==24134== ==24134== Warning: segment-override prefix encountered, but thread has no LDT ==24134== Warning: segment access: virtual addr 8 exceeds segment limit of 0 ==24134== Invalid read of size 4 ==24134== at 0x4023912C: __pthread_alt_lock (in /lib/i686/libpthread-0.10.so) ==24134== by 0x40235D76: __GI___pthread_mutex_lock (in /lib/i686/libpthread-0.10.so) ==24134== by 0x4202AE54: __cxa_atexit_internal (in /lib/i686/libc-2.3.2.so) ==24134== by 0x4201589F: __libc_start_main (in /lib/i686/libc-2.3.2.so) ==24134== Address 0x8 is not stack'd, malloc'd or free'd Any ideas would be appreciated. Thanks, Rich |
|
From: Melchior F. <mf...@kd...> - 2003-08-04 14:29:18
|
* Tom Hughes -- Monday 04 August 2003 16:14: > Well it does in that case, yes. But you might be deleting it in > a different source file from the one where it was allocated and > then the compiler wouldn't have a hope of knowing! True. And expecting the compiler to store the type of allocation for cases like this is asked a bit too much, even it it could do so. After all, this construct hasn't any merits anyway. I'll fix this in that code, which is =not= =my= code. :-) m. |
|
From: Tom H. <th...@cy...> - 2003-08-04 14:15:44
|
In message <200...@pf...>
Melchior FRANZ <mf...@kd...> wrote:
> * Zeljko Vrba -- Monday 04 August 2003 15:36:
>> On Mon, Aug 04, 2003 at 02:39:15PM +0200, Melchior FRANZ wrote:
>> > 1209: void* pData = new unsigned char[embeddedItem.iDataSize];
>> > ...
>> > 1217: delete[] pData;
>
>> You can't use either delete nor delete[] on void* since the compiler must
>> know the exact type in order to call destructor for the object(s)
>
> Well, the compiler does very well know the type. It was the one
> who allocated it, remember? :-}
Well it does in that case, yes. But you might be deleting it in
a different source file from the one where it was allocated and
then the compiler wouldn't have a hope of knowing!
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Melchior F. <mf...@kd...> - 2003-08-04 13:51:03
|
* Zeljko Vrba -- Monday 04 August 2003 15:36: > On Mon, Aug 04, 2003 at 02:39:15PM +0200, Melchior FRANZ wrote: > > 1209: void* pData = new unsigned char[embeddedItem.iDataSize]; > > ... > > 1217: delete[] pData; > You can't use either delete nor delete[] on void* since the compiler must > know the exact type in order to call destructor for the object(s) Well, the compiler does very well know the type. It was the one who allocated it, remember? :-} I wasn't sure about this, and Stroustrup didn't tell me. > So valgrind is not wrong, your code is. It isn't =my= code. I'm just debugging someone else's. m. PS: Please don't CC to me. I'm subscribed! |
|
From: Zeljko V. <zel...@av...> - 2003-08-04 13:41:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Aug 04, 2003 at 02:39:15PM +0200, Melchior FRANZ wrote: > > The concerned code in this case is (without the line numbers): > > 1209: void* pData = new unsigned char[embeddedItem.iDataSize]; > ... > 1217: delete[] pData; > > > If I replace the silly "void *" by "unsigned char" then the mismatch > is not reported. (This isn't my code!) The new and delete are used > correctly, only the allocated memory is assigned to a void *. Does > this break the necessary information for gcc to use delete correctly? > Shouldn't the compiler know better, or is it a valgrind problem? > You can't use either delete nor delete[] on void* since the compiler must know the exact type in order to call destructor for the object(s) (delete MUST call destructors). I don't know the relevant part of the standard, but it's just common sense... :) So valgrind is not wrong, your code is. - -- v Zeljko Vrba, dipl. ing. http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3B375F1C zel...@av... Advanced Simulation Technologies http://www.avl.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/LmFAzT2jbzs3XxwRAvakAKCtxbjNaMUFJ5sbclep58JuXbCCSwCfUPpp oafI0uSrxT7gmsL5WwTNSIA= =JKk2 -----END PGP SIGNATURE----- |