Created attachment 861584 [details] log of test run Description of problem: I ran the tapsets included in icedtea6 against java-1.8.0-openjdk rpm and got a few failures: Working probes: 464 Broken probes: 34 Broken jstack tests: 10 Version-Release number of selected component (if applicable): java-1.8.0-openjdk-1.8.0.0-0.25.b126.fc20.x86_64 java-1.8.0-openjdk-devel-1.8.0.0-0.25.b126.fc20.x86_64 java-1.8.0-openjdk-debuginfo-1.8.0.0-0.25.b126.fc20.x86_64 Steps to Reproduce: 1. # yum install java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-debuginfo 2. Set up systemtap as indicated in user guide: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/using-systemtap.html#using-setup 3. $ hg clone http://icedtea.classpath.org/hg/icedtea6 4. $ cd icedtea6/test/tapset/ 5. $ ./jstaptest.pl -J /usr/lib/jvm/java-1.8.0-openjdk.x86_64/ -o log Actual results: Working probes: 464 Broken probes: 34 Broken jstack tests: 10 Expected results: Working probes: 498 Broken probes: 0 Broken jstack tests: 0 Additional info:
Created attachment 886488 [details] JNIStapTest.c patch Hey, I've been looking into the test result regressions. The majority of the fails were because the JNIStapTest.c internal representation of the 'type' string was allocated and not zero'd before strcmp'ing with the 'type' passed for that test. Zeroing out the malloc'd string before comparison fixed this for me (patch attached). hotspot.jni.FatalError and hotspot.jni.GetFieldID testcases both failed with a systemtap user_string copy error, which means it is likely the string was paged out before we could access it. I believe the probe point still works. hotspot.jni.GetVersion.return - this now returns '10008' instead of '10006' so this test fails simply because the string we expect has changed. hotspot.jni.NewObjectA.return - again this seems to be an issue with the string we check for instead of an incorrect test result. In the test we use `grep "NewObjectAret=[^0]"` switching this to `grep "NewObjectAret=0"` results in a successful test. Currently the jstack tests still fail for me with warnings about no matching debuginfo (despite the fact the previous tests run), I'll be digging more into this next.
(In reply to Lukas Berk from comment #1) > Currently the jstack tests still fail for me with warnings about no matching > debuginfo (despite the fact the previous tests run), I'll be digging more > into this next. This might be a problem with our debuginfo generation. We are currently doing exactly what upstream said is the 'correct' way: http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012039.html But there are other reports that this is not sufficient: http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012319.html
Created attachment 886623 [details] JNIStapTest.c patch v2 Re-submitted the patch with the proper size in the memset, status of the tests remains the same.
Thanks for the patch Lukas! The second version looks technically correct to me. We could probably add this as a patch to rpm, except I don't think the packages include these tests. For upstreaming to IcedTea, I'd actually prefer to spend a bit more time, go through the whole test and either add similar defensive memset calls at malloc call sites, or possibly switch over to calloc. (in addition to fixes to the other one-off issues with expected output that Lukas noted). Omair, since this seems to be a bug in the tests, rather than a bug in openjdk package, can this bug be closed? Also, I highly suspect you are correct about the jstack tests failing due to openjdk debuginfo issues. I think we should treat that as separate issue. (Is there already a bug for that? I searched and did not find one.)
(In reply to Jon VanAlten from comment #4) > Omair, since this seems to be a bug in the tests, rather than a bug in > openjdk package, can this bug be closed? Yes, I will do it. > Also, I highly suspect you are correct about the jstack tests failing due to > openjdk debuginfo issues. I think we should treat that as separate issue. > (Is there already a bug for that? I searched and did not find one.) There's no bug for it, but I am aware of the issue and will be fixing it.