On Tue, 2012-04-17 at 21:02 +0200, Folkert van Heusden wrote: > > Valgrind provides a simulated cpu, but not a simulated OS and > > simulated mmu etc etc. > > In other words, Valgrind runs a "unix application process" on > > top of a virtual cpu, Valgrind does not provide a virtual > > machine like kvm or Xen or ... > > hmmm ok. > it seems it can't handle corruptions that nicely: Not too sure I understand. The below msgs from Valgrind are indicating (probable/possible) bugs. Apart of reporting the error, the behaviour is (usually) not influenced too much (compared to a native execution). malloc-fill might cause bigger differences, in case non initialised memory is used.
Or do you mean the stack trace is not that good/clear ? Maybe the gdb+Valgrind gdbserver will give better stack traces ? Philippe > > ==21521== at 0x6A39957: ioctl (syscall-template.S:82) > ==21521== by 0x40A8B44: ukiCreateContext (in > /usr/lib/x86_64-linux-gnu/libatiuki.so.1.0) > ==21521== by 0xF808A35: ??? (in /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so) > ==21521== by 0x1016A3AF: ??? > ==21521== by 0x10169467: ??? > ==21521== by 0x1016956F: ??? > ==21521== by 0xF862E0F: ??? (in /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so) > ==21521== by 0xF: ??? > ==21521== Address 0x7feff2528 is on thread 1's stack > ==21521== Uninitialised value was created by a stack allocation > ==21521== at 0xDEE4168: ??? (in /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so) ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
