On 14.04.2015 21:24, Philippe Waroquiers wrote: > 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 defined a gdb-macro for this: define get_vbits printf "# mon get_vbits 0x%lx 0x%lx\n" , &$arg0 , sizeof($arg0) eval "mon get_vbits 0x%lx 0x%lx" , &$arg0 , sizeof($arg0) end Then I can run: (gdb) get_vbits i_Cond # mon get_vbits 0xffefff8bf 0x1 00 (gdb) For the case above, you should check the instruction triggering the error. (gdb) x/i $rip Then you know in what register to look for. with the complete disassembly you might be able to track down what it exactly was. Then look near the problematic instruction. (gdb) disassemble /m I think there was also some option to switch valgrind so that the definedness of registers can be checked: --vgdb-shadow-registers=yes Regards Matthias ------------------------------------------------------------------------------ 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
