https://bugs.kde.org/show_bug.cgi?id=496552
--- Comment #6 from Paul Floyd <pjfl...@wanadoo.fr> --- There's still a lot to read there. Some general comments about when memcheck can at least seem to get things wrong. I'll start with invalid reads and writes. In order for memcheck to get this wrong it must fail to correctly redirect allocation and deallocation functions or it must fail to have the right information on stack limits. In this case it looks like the stack. Uninitialized memory is more difficult since there are so many ways of doing things with memory. It's a narrow path to tread between ignoring harmless optimizations, missing genuine errors and generating excessive noise. Back to invalid stack issues. Debugging this kind of thing isn't straightforward. On the memcheck side you can check the logs and memory maps and debug combinations of Valgrind and the guest exe. On the guest you need to know exactly what the intent of the code is. That's probably the hardest bit. If you aren't a JVM developer then matching what the JVM is doing with what memcheck is seeing and reporting. I don't know if it's possible to mix java debuggers with memcheck running under gdb or memcheck with vgdb or both. If you can reproduce the issues outside of your test framework I would suggest starting with vgdb. That's usually a great way of poking around with the guest at the moment of an error. You'll probably need to use a suppression file to get past all those initial uninitialized memory errors. -- You are receiving this mail because: You are watching all bug changes.
