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
(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: Guilherme L. <li...@fn...> - 2003-08-05 22:44:32
|
Hi,
I am using valgrind 1.9.6 to analyse a small program:
----------------
1 #include <string>
2 using std::string;
3 int main() {
4 string leak("Does this cause a memory leak?");
5 string* ok = new string("This does not cause any memory leaks");
6 delete ok;
7 return 0;
8 }
-----------------
The commands:
> g++ -g -o test test.cpp
> valgrind --leak-check=yes --show-reachable=yes ./test
Shows:
----------------
...(removed)...
==3406== LEAK SUMMARY:
==3406== definitely lost: 0 bytes in 0 blocks.
==3406== possibly lost: 0 bytes in 0 blocks.
==3406== still reachable: 1920 bytes in 1 blocks.
==3406== suppressed: 0 bytes in 0 blocks.
----------------
The traceback points to line 4 in test.cpp source file.
The questions are:
1) Does "still reachable" report a real memory leak?
2) Do "definitely lost" and "possibly lost" reports
always mean memory leaks?
3) Are there situations when "possibly lost" does not
come from a memory leak? If so, can someone post
a code snippet where such a situation has been
isolated?
Thanks,
Guilherme
|
|
From: Jeremy F. <je...@go...> - 2003-08-05 16:50:12
|
On Tue, 2003-08-05 at 04:32, Nicholas Nethercote wrote: > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Valgrind caught a segmentation fault in your program, see last error > message for an explanation of what caused it; aborting. > > ? > > Presumably, if the client program has its own SIGSEGV handler, Valgrind > couldn't do this. Right, but it presumably has a good reason for having a SEGV handler. > One possible downside -- by not dumping core naturally, could you be > losing useful information (eg. where it happened) from the core file? I'm > not sure. Core dumps for seg faults within a client app running under > Valgrind are usually useless, though, as they occur in generated code. > Hmm. I actually do this in the syscall/signal patch. I set up a handler for all the signals which are SIG_DFL, and print a message if the result will be fatal. The obvious extension to this is to also print a stacktrace if it is a terminate w/ core signal (maybe a trace of all threads' stacks). You still need to take the signal so the process exits with the right exit code. The parent process may be relying on it. Obviously the coredump generated will be basically useless, since it is a coredump of your code as run by Valgrind, so gdb will have no idea of what to make of it. But the trace should help, along with previous messages. J |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 15:04:01
|
On 5 Aug 2003, Paul A. Clarke wrote:
> I'd suggest that these recent threads about Valgrind not
> detecting/reporting invalid write attempts to read-only memory are at
> least justifications for adding something either to the FAQ or to the
> documentation (section 2.12, "Limitations"?), or both.
>
> I could take a stab at it, if someone in the project thinks it
> worthwhile, and nobody volunteers. (I'm not an expert in the area, but
> this is probably only a couple of sentences, right?)
Yep... how about this:
Q. My program dies with a segmentation fault, but Valgrind doesn't give
any error messages before it, or none that look related.
A. The one kind of segmentation fault that Valgrind won't give any
warnings about is writes to read-only memory. Maybe your program is
writing to a static string like this:
char* s = "hello";
s[0] = 'j';
or something similar.
Seem reasonable?
----
I've said that it's very hard/impossible to add such read-only write
checking to Valgrind's memory checker (Memcheck) without adding much
complexity and slowing it down more. However, it would be pretty easy to
write a new skin that checks specifically for this. It could be used as a
backup for Memcheck -- when you get a seg fault that Memcheck doesn't
diagnose, you could run your program through the new skin and (hopefully)
it would tell you where you wrote to read-only memory.
All this assumes that read-only writes are the only seg fault-causing
operations that Valgrind doesn't watch out for. I think this is true, but
not 100% certain.
N
|
|
From: Paul A. C. <pa...@us...> - 2003-08-05 14:48:50
|
I'd suggest that these recent threads about Valgrind not detecting/reporting invalid write attempts to read-only memory are at least justifications for adding something either to the FAQ or to the documentation (section 2.12, "Limitations"?), or both. I could take a stab at it, if someone in the project thinks it worthwhile, and nobody volunteers. (I'm not an expert in the area, but this is probably only a couple of sentences, right?) Regards, Paul Clarke On Tue, 2003-08-05 at 05:02, Nicholas Nethercote wrote: > 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. ... > As I said, the dump for the program above is caused by writing to > read-only memory. On Tue, 2003-08-05 at 09:10, Igmar Palsenberg wrote: > I've already requested this feature, since writing to read-only memory in > threads isn't debuggable by both gdb and valgrind. At least telling me > that the write is to read-only memory would help :) |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 14:10:37
|
> char* x = "test";
>
> x[5] = 'x'; // the same as above
>
> printf("%s\n", x ); // causes memory dump
No, it doesn't. The cause is the x[5] = 'x';, since that is a read-only
segment in memory. I never reaches the printf(), which gdb would tell you.
I've already requested this feature, since writing to read-only memory in
threads isn't debuggable by both gdb and valgrind. At least telling me
that the write is to read-only memory would help :)
Igmar
|
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:57:44
|
> > 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'.
GCC 3.x adds far more padding and alignment than 2.95.x does. No idea what
the reason is, but I observed that when debugging with code generated by
gcc -S
> 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? :)
I've seen a number of occasions when valgrind is totally of the track, all
of them with threaded apps screwing up each other stack. Gives nice
extremely hard to track problems :)
Igmar
|
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:54:02
|
> 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. Why all this trouble for a NULL pointer dereference ? If you can't debug those, you can't debug the rest. Most weird cores happen when doing something else, like double free()'s, screwing up TLS when using pthread's, etc. Adding code if thing would core is a a huge job to do. Most valgrind related core's I've seen come after a valgrind assert. > 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... Reeducate your programmers. Take my word, valgrind cores are rare and mostly obvious. It it cores with valgrind, it usually also does without. Igmar |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:45:57
|
> 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. That changes program behaviour, that's bad. After a core the program's state is undefined, so I see no reason to ask questions. The program will core, with or without valgrind. > 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. I debug complicated programs, and the above is the least of your programs, especially when threads are involved. Igmar |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:42:30
|
> The following programm causes a core:
> int main( int argc, char** argv )
> {
> int *a = NULL;
>
> int b = *a;
>
> return 0;
> }
It does. It should.
> 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.
Valgrind is a part of your apps's addresspace. Valgrind doesn't core, your
app does. The current behaviour is correct, I can't think of any reason
to change it.
Igmar
|
|
From: Josef W. <Jos...@gm...> - 2003-08-05 12:08:57
|
On Tuesday 05 August 2003 13:32, Nicholas Nethercote wrote: > On Tue, 5 Aug 2003, Josef Weidendorfer wrote: > > 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. > > Ok, would you (and Borg) be happy if instead of saying this: For me personally, this is no big issue. I'm totally fine with the current situation (I'm not using Valgrind that often, mainly because I can't use Valgrind in my Valgrind skin ;-). But IMHO, the error message below is much more user friendly. > > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Segmentation fault (core dumped) > > Valgrind said something like: > > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Valgrind caught a segmentation fault in your program, see last error > message for an explanation of what caused it; aborting. > > ? > > Presumably, if the client program has its own SIGSEGV handler, Valgrind > couldn't do this. Isn't it possible to inject some trap into the programs SIGSEGV handler, to allow for the error message? Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 11:32:33
|
On Tue, 5 Aug 2003, Josef Weidendorfer wrote: > 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. Ok, would you (and Borg) be happy if instead of saying this: ==8968== Invalid write of size 4 ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) ==8968== by 0x8048264: ??? (start.S:81) ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd Segmentation fault (core dumped) Valgrind said something like: ==8968== Invalid write of size 4 ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) ==8968== by 0x8048264: ??? (start.S:81) ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd Valgrind caught a segmentation fault in your program, see last error message for an explanation of what caused it; aborting. ? Presumably, if the client program has its own SIGSEGV handler, Valgrind couldn't do this. One possible downside -- by not dumping core naturally, could you be losing useful information (eg. where it happened) from the core file? I'm not sure. Core dumps for seg faults within a client app running under Valgrind are usually useless, though, as they occur in generated code. Hmm. I'm not saying the change will happen, BTW -- lots of people have used Valgrind without finding the current situation problematic. But it's good to know what is the minimum change that would fix the perceived problem :) N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-05 10:55:26
|
> 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. You got me thinking... I could think of setting a signal handler to the routine we want to call, raising that signal, and then modifying the stack and returning. Hmmm, I don't think I want to try that :) -- Vincent Penquerc'h |
|
From: Erik C. <er...@ar...> - 2003-08-05 10:53:33
|
On Tue, Aug 05, 2003 at 11:29:39AM +0100, Nicholas Nethercote wrote:
> >
> > 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'.
I think it could be because I got the stack growth direction wrong.
This one crashes like it should.
void main()
{
int *b;
char a[4];
int c;
b = &c;
a[7] = 123; // Oops!
*b = 456; // Boom!
}
> 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? :)
No objection. Valgrind gives an error message before the seg fault.
Unfortunately the error message relates to the "Boom" and not the
"Oops" line, so it's not very useful in this sort of case. The
only answer is a version of gcc with fat pointers like the one I
linked to.
By the way, I don't think Purify or Electric Fence can catch this
one either, and the nasty thing about it is that it's often a latent
bug that waits for the right (wrong) input, so you can't catch it
except by sitting down and reasoning about the program. That applies
even to Java, where you can easily get the array bounds exception far
too late (after the program started being used for real work).
--
Erik Corry er...@ar...
|
|
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
|