|
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: <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 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: <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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Ranko Z. <ra...@sp...> - 2003-08-06 01:58:54
|
How about:
valgrind --gdb-attach=3Dyes your_prog
You can examine your code, backtrace and everything else before it genera=
tes
the core.
R.
> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...]On Behalf Of
> Bor...@pd...
> Sent: 05 August 2003 11:16
> To: nj...@ca...
> Cc: val...@li...
> Subject: AW: [Valgrind-users] core for null pointer access
>
>
> I think a correct behaviour would be something to ask the user if he wa=
nts
> 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.
> The way valgrind handles this situation now, seems like a not well defi=
ned
> behaviour of valgrind in itself. With the above mentioned method, the u=
ser
> 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-Poin=
ter
> Access gets much more complicated than my little example programm. For
> example by passing of an NULL pointer as function parameter through som=
e
> 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...]
> 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
> > x86-linux. =3D=3D26211=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, =
by Julian
> > Seward. =3D=3D26211=3D=3D Using valgrind-20030725, a program supervis=
ion
> > framework for x86-linux. =3D=3D26211=3D=3D Copyright (C) 2000-2003, a=
nd GNU
> > GPL'd, by Julian Seward. =3D=3D26211=3D=3D Estimated CPU clock rate i=
s 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.o=
ut)
> > =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 b=
y
> > it's self.
>
> Really? What do you think would be the right way to handle this proble=
m
> correctly?
>
> N
>
>
> -------------------------------------------------------
> 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_072
> 303_01/01
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|