https://bugs.kde.org/show_bug.cgi?id=496552
--- Comment #3 from Bill Torpey <wallstp...@gmail.com> --- Thanks for the quick reply! Please see my embedded comments below: > That's a lot of errors. Unless you have solid proof you should assume that > ... > errors really are benign then you should use a suppression file. We do something similar -- using the scripts (https://github.com/nyfix/memleaktest) we filter out any reports that don't have at least some of our own code in the stack trace. > ==10:51:28.895572 24239== Invalid write of size 4 Since these don't include our code in the stack we just ignore them. The JVM does some VERY weird stuff, and as you point out the actual Java code is invisible to valgrind, gdb, etc. That's OK because for this we're only interested in testing the JNI code. > > Thirdly there are some invalid reads. > ... > doesn't that cause a segfault? Funny you should mention it. It turns out that the JVM catches SEGV's rather than checking for NULL (https://jcdav.is/2015/10/06/SIGSEGV-as-control-flow/), so that's "normal" for the JVM. One more reason why we ignore anything that doesn't include our code on the stack. > Finally errors like > ==11:43:12.263417 24239== Invalid read of size 8 > ==11:43:12.263493 24239== at 0x4AA74E3: vfprintf (in > /usr/lib64/libc-2.17.so) > ... > That looks like it is in your code. You should be able to examine the source > to work out what is wrong. Yup, and I've reviewed the code and as far as I can tell it's clean. Not to mention we have literally hundreds of tests using both valgrind and Address Sanitizer that say it's clean. So why all of a sudden does valgrind flag it in this one test? One question I have is about the following: ==11:43:12.062730 24239== Address 0x4df05f58 is on thread 61's stack ==11:43:12.062735 24239== in frame #0, created by snprintf (???:) What does this mean? We already know that the address is on thread 61's stack (the current thread, I believe) and that it's in frame #0 (the current top-most frame), So what's the problem? I can only guess that the JVM is doing something funky that is confusing valgrind, but I would very much like to know if you think that is plausible? Thanks again for taking the time to review! -- You are receiving this mail because: You are watching all bug changes.
