On Tue, 2015-04-14 at 19:26 +0100, "João M. S. Silva" wrote: > > What you can further do is to use the memcheck monitor commands to > > examine the definedness of the variables used on the line where the > > error is detected. > > > > See manual for more info > > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands > > Thanks, I didn't know about the "monitor get_vbits" command. > > However, it seems I'm not able to catch any uninitialized variable. I do not understand. The below error is an uninitialised value error. Why do you say you cannot catch the errors ? You just have to use monitor get_vbits at the time of the error to investigate more in depth where the error comes from, and if needed, relaunch the execution after having added some breakpoints earlier in the program flow, and again use get_vbits to try to understand where the uninit error comes from.
> I > also get this kind of error in another library: > > ==17108== Use of uninitialised value of size 8 > ==17108== at 0x60BDB6D: decode_rs_char (decode_rs.h:118) > ==17108== by 0x41D9B5: Code::decode(unsigned char*, int*, unsigned > int, bool) (Code.cpp:114) > ==17108== by 0x41E6D8: Code::extract(char*, char*, std::string&, > unsigned int) (Code.cpp:326) > ==17108== by 0x4060E4: main (test.cpp:178) > ==17108== Uninitialised value was created by a stack allocation > ==17108== at 0x60BD480: decode_rs_char (decode_rs_char.c:15) > > And with vgdb I get this in gdb: > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000000060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 "", > eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118 > 118 tmp = INDEX_OF[lambda[j - 1]]; Yes that is the way the valgrind gdbserver reports to gdb that there is an error that the user can look at. > > I tried the get_vbits command in variables p, data, eras_pos and > no_eras. I had to manually find out the size of the corresponding > variables, since some of them are pointers or structs with pointer fields. Yes, the monitor get_vbits only knows about address+length. So, you need to do something like (gdb) p &myvar (gdb) p sizeof(myvar) and then use (gdb) monitor get_vbits <address> <size> to get the vbits. > > I seem to have computed the corresponding sizes correctly since if I use > a size 1 byte larger in the vget_bits command I get an "unaddressable" > warning (also represented by the underscore). > > When you say "local variables" you mean the variables the function > received as argument or all variables defined inside the function? When valgrind reports that the origin of an uninit var is in a function, then it means it is one of the local variables of the function. Not the arguments of this function. > > I think I know the answer, since I remember having discussed this in the > mailing list: all variables inside the function are local, thus > allocated in the stack, so valgrind is not yet able to detect errors in > them? Can you confirm this? Valgrind memcheck is able to report some errors originating from local vars, namely the uninit errors. > > I have to try using exp-sgcheck, right? If you want to detect buffer over or under run in stack and global variables, then yes, the experimental exp-sgcheck tool is your friend. Philippe ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
