|
From: Roland M. <rol...@nr...> - 2012-05-30 23:17:58
|
Hi! ---- While digging through the output of valgrind's 3.7.0's "exp-sgcheck" I came across this valgrind hit: -- snip -- ==7296== Invalid read of size 1 ==7296== at 0x44F4CB: nv_create (name.c:1084) ==7296== by 0x450698: nv_open (name.c:1414) ==7296== by 0x446AB1: varsub (macro.c:1304) ==7296== by 0x44463F: copyto (macro.c:633) ==7296== by 0x442DFA: sh_macexpand (macro.c:246) ==7296== by 0x443A5F: sh_macpat (macro.c:424) ==7296== by 0x47929D: sh_exec (xec.c:2824) ==7296== by 0x476E8F: sh_exec (xec.c:2208) ==7296== by 0x476D60: sh_exec (xec.c:2177) ==7296== by 0x47B461: sh_funscope (xec.c:3409) ==7296== by 0x47BAB1: sh_funct (xec.c:3493) ==7296== by 0x474A8C: sh_exec (xec.c:1533) ==7296== by 0x40E6BA: exfile (main.c:600) ==7296== by 0x40D8A4: sh_main (main.c:373) ==7296== by 0x40CAA8: main (pmain.c:45) ==7296== Address 0x7da43f expected vs actual: ==7296== Expected: unknown ==7296== Actual: global array "x1_numbuff" of size 523 in object with soname "NONE" -- snip -- IMO it would be nice to print the address of the "Invalid read" in line 1 and give the address of the object being affected (i.e. 'global array "x1_numbuff"' in this case). I would've saved us a lot of digging today... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Philippe W. <phi...@sk...> - 2012-05-30 23:42:27
|
On Thu, 2012-05-31 at 01:17 +0200, Roland Mainz wrote: > IMO it would be nice to print the address of the "Invalid read" in > line 1 and give the address of the object being affected (i.e. 'global > array "x1_numbuff"' in this case). I would've saved us a lot of > digging today... If you need more info about an error context, you can always use the Valgrind gdbserver : when the error is reported, you have full access to all the variables etc. Philippe |
|
From: Roland M. <rol...@nr...> - 2012-05-30 23:53:16
|
On Thu, May 31, 2012 at 1:42 AM, Philippe Waroquiers <phi...@sk...> wrote: > On Thu, 2012-05-31 at 01:17 +0200, Roland Mainz wrote: > >> IMO it would be nice to print the address of the "Invalid read" in >> line 1 and give the address of the object being affected (i.e. 'global >> array "x1_numbuff"' in this case). I would've saved us a lot of >> digging today... > If you need more info about an error context, you can always use > the Valgrind gdbserver : when the error is reported, you > have full access to all the variables etc. Erm... AFAIK having the address of the "hit" and the address of the affected array is more or less essential to see _where_ such things happen (e.g. at the start, middle or end of an array). I know I can attach a debugger but getting the info from "exp-sgcheck" would be better (doesn't "memcheck" do that by default) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Dan S. <dan...@go...> - 2012-05-31 18:41:51
|
On 31 May 2012 01:42, Philippe Waroquiers <phi...@sk...> wrote: > On Thu, 2012-05-31 at 01:17 +0200, Roland Mainz wrote: > >> IMO it would be nice to print the address of the "Invalid read" in >> line 1 and give the address of the object being affected (i.e. 'global >> array "x1_numbuff"' in this case). I would've saved us a lot of >> digging today... > If you need more info about an error context, you can always use > the Valgrind gdbserver : when the error is reported, you > have full access to all the variables etc. Philippe, the use of gdbserver should be optional, right? The output of exp-sgcheck is currently not enough to glance where the problem happens so you have to use gdb *everytimes*. This should not be required. |
|
From: Philippe W. <phi...@sk...> - 2012-05-31 20:11:21
|
On Thu, 2012-05-31 at 20:41 +0200, Dan Shelton wrote: > On 31 May 2012 01:42, Philippe Waroquiers <phi...@sk...> wrote: > > On Thu, 2012-05-31 at 01:17 +0200, Roland Mainz wrote: > > > >> IMO it would be nice to print the address of the "Invalid read" in > >> line 1 and give the address of the object being affected (i.e. 'global > >> array "x1_numbuff"' in this case). I would've saved us a lot of > >> digging today... > > If you need more info about an error context, you can always use > > the Valgrind gdbserver : when the error is reported, you > > have full access to all the variables etc. > > Philippe, the use of gdbserver should be optional, right? The output > of exp-sgcheck is currently not enough to glance where the problem > happens so you have to use gdb *everytimes*. This should not be > required. Yes, for sure, the use of gdbserver should be optional. If it is normal to output some info in an error msg, then it should be output. In the case above, the gdbserver indication was just say that it can help, waiting for a possible improvement. Note I might have missed something in the original request, because I understand the address of the 'wrong read' is given in the error msg. Unless I missed something, the thing missing was the address of the global variable. Roland, do you confirm that effectively it is only the address of the global array which was missing ? (otherwise; I do not understand what is the Address 0x7da43f in the below. ==7296== Address 0x7da43f expected vs actual: ==7296== Expected: unknown ==7296== Actual: global array "x1_numbuff" of size 523 in object with soname "NONE" Philippe |
|
From: Roland M. <rol...@nr...> - 2012-06-15 23:28:41
|
On Thu, May 31, 2012 at 10:11 PM, Philippe Waroquiers <phi...@sk...> wrote: > On Thu, 2012-05-31 at 20:41 +0200, Dan Shelton wrote: >> On 31 May 2012 01:42, Philippe Waroquiers <phi...@sk...> wrote: >> > On Thu, 2012-05-31 at 01:17 +0200, Roland Mainz wrote: >> > >> >> IMO it would be nice to print the address of the "Invalid read" in >> >> line 1 and give the address of the object being affected (i.e. 'global >> >> array "x1_numbuff"' in this case). I would've saved us a lot of >> >> digging today... >> > If you need more info about an error context, you can always use >> > the Valgrind gdbserver : when the error is reported, you >> > have full access to all the variables etc. >> >> Philippe, the use of gdbserver should be optional, right? The output >> of exp-sgcheck is currently not enough to glance where the problem >> happens so you have to use gdb *everytimes*. This should not be >> required. > Yes, for sure, the use of gdbserver should be optional. > If it is normal to output some info in an error msg, then it > should be output. In the case above, the gdbserver indication was > just say that it can help, waiting for a possible improvement. > > Note I might have missed something in the original request, > because I understand the address of the 'wrong read' is given > in the error msg. > Unless I missed something, the thing missing was the address of > the global variable. > > Roland, do you confirm that effectively it is only the address > of the global array which was missing ? > (otherwise; I do not understand what is the Address 0x7da43f in the > below. > > ==7296== Address 0x7da43f expected vs actual: > ==7296== Expected: unknown > ==7296== Actual: global array "x1_numbuff" of size 523 in object > with soname "NONE" Erm... the problem was that I don't have the address of the array "x1_numbuff" as reference point. Example: We got this output from valgrind... -- snip -- ==7296== Invalid read of size 1 ==7296== at 0x44F4CB: nv_create (name.c:1084) ==7296== by 0x450698: nv_open (name.c:1414) [snip] ==7296== by 0x40CAA8: main (pmain.c:45) ==7296== Address 0x7da43f expected vs actual: ==7296== Expected: unknown ==7296== Actual: global array "x1_numbuff" of size 523 in object with soname "NONE" -- snip -- ... but IMO be better would be... -- snip -- ==7296== Invalid read of size 1 ==7296== at 0x44F4CB: nv_create (name.c:1084) ==7296== by 0x450698: nv_open (name.c:1414) [snip] ==7296== by 0x40CAA8: main (pmain.c:45) ==7296== Address 0x7da43f expected vs actual: ==7296== Expected: unknown ==7296== Actual: global array "x1_numbuff" [address 0xchickenmonster] of size 523 in object with soname "NONE" -- snip -- (yes, yes, I know... "chickenmonster" is not a valid hexadecimal value :-) ) Or short: Each time a variable name is printed it's address should be printed, too. That helps a lot in finding the right place to look _and_ it helps if the code has multiple variables with the same name but different addresses (yeah... I had this specific kind of hell this week). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Philippe W. <phi...@sk...> - 2012-06-16 06:54:07
|
On Sat, 2012-06-16 at 01:28 +0200, Roland Mainz wrote:
> Or short: Each time a variable name is printed it's address should be
> printed, too. That helps a lot in finding the right place to look
> _and_ it helps if the code has multiple variables with the same name
> but different addresses (yeah... I had this specific kind of hell this
> week).
At least for global arrays, adding the address looks easy.
Index: exp-sgcheck/sg_main.c
===================================================================
--- exp-sgcheck/sg_main.c (revision 12643)
+++ exp-sgcheck/sg_main.c (working copy)
@@ -966,8 +966,9 @@
break;
case Inv_Global:
str = "array";
- VG_(sprintf)(buf, "global %s \"%s\" of size %'lu in object with soname \"%s\"",
+ VG_(sprintf)(buf, "global %s \"%s\" of address %p size %'lu in object with soname \"%s\"",
str, inv->Inv.Global.nd->descr->name,
+ inv->Inv.Global.nd->addr,
inv->Inv.Global.nd->descr->szB,
inv->Inv.Global.nd->descr->soname );
break;
The new output is:
==24431== Invalid read of size 2
==24431== at 0x4004B3: main (globalerr.c:12)
==24431== Address 0x60089e expected vs actual:
==24431== Expected: global array "b" of address 0x600890 size 14 in object with soname "NONE"
==24431== Actual: unknown
==24431== Actual: is 0 after Expected
Note however that 0x60089e = 0x600890 + size 14 + 'is 0 after Expected'
In this, the current error msg gives all elements but one.
So, the last one can be derived from the others.
The above patch is trivial (would need to update the doc and the tests).
I would prefer to have feedback from Julian on this before working further.
The best is to put a wishlist in bugzilla.
Philippe
|