On Tue, 2015-04-14 at 22:03 +0100, "João M. S. Silva" wrote: > > Yes, but in some cases the sizeof indicates the size of the pointer (not > the size of the allocated memory). So I had to browse the code to get > the size of the allocations/structs involved. or use (gdb) monitor v.info location <addr>
You might also better start your valgrind with --read-var-info=yes That might give some more information in some cases (valgrind will be slower to startup). > OK, so it is not applicable to this case of uninitialized stack variables. sg-check will not help for such an uninit. > > What is strange is that I never faced such a shortcoming in my own code. > In my code valgrind always points to the location of the error exactly. > Does this happen because this is a library that I link with? Or because > of the nature of the error? Depends on what errors you had in your code. Uninit errors can be more difficult to track than leaks or dangling pointers, in particular because the origin of uninit data is not precisely maintained. 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
