[PATCH] jstaptest.pl: Expect non-zero value for hotspot.jni.NewObjectA.return

[Mark Wielaard]

On Wed, Aug 08, 2012 at 01:43:51PM -0400, Jon VanAlten wrote:
> ----- Original Message -----
> > From: "Mark Wielaard" <mjw at redhat.com>
> > While testing the tapset-jstack support I kept getting one failure
> > for the tapset-probe tests. hotspot.jni.NewObjectA.return is
> > expecting
> > to get a zero return value. But that doesn't make sense to me since
> > it would only return zero on failure, and the test program does seem
> > to want the call to succeed. The similar hotspot.jni.NewObject.return
> > and hotspot.jni.NewObjectV.return do expect a non-zero return. So I
> > changed hotspot.jni.NewObjectA.return to expect the same.
> > 
> > I don't know why I hadn't noticed this before. Maybe because this
> > systemtap bug could occasionally get something wrong and I never
> > investigated deeply before?
> > http://sourceware.org/bugzilla/show_bug.cgi?id=14434
> > 
> > Anyway, with this in place make check-tapset gets a perfect score
> > each and every time. Does it look sane?
> 
> Yes it does, and good catch!  OK to commit AFAICT.

I applied it and backported to icedtea6. On both 7 and 6 I now see:

$ make check-tapset -k
/home/mark/src/icedtea6/test/tapset/jstaptest.pl \
  -B /home/mark/icedtea6-obj/openjdk.build -A amd64 \
  -S /home/mark/src/icedtea6/test/tapset \
  -a test/check-stap.log -p
Compiling tests.
Check whether we have enough privs to run systemtap script...
OK
Testing if systemtap can match probes.
..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Testing if detected probes work as expected.  This may take a while...
..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Working probes:     498
Removing compiled test files.
/home/mark/src/icedtea6/test/tapset/jstaptest.pl \
  -B /home/mark/icedtea6-obj/openjdk.build -A amd64 \
  -S /home/mark/src/icedtea6/test/tapset \
  -a test/check-stap.log -j
Compiling tests.
Check whether we have enough privs to run systemtap script...
OK
Testing if jstack works as expected with ''...
..
Testing if jstack works as expected with '-XX:+UseCompressedOops'...
..
Testing if jstack works as expected with '-XX:-UseCompressedOops'...
..
Testing if jstack works as expected with '-XX:+UseCompressedOops -Xmx5G'...
..
Testing if jstack works as expected with '-XX:-UseCompressedOops -Xmx5G'...
..
Working jstack tests:     10
Removing compiled test files.

So that looks good.

That is on Fedora 17 x86_64 with GCC 4.7.1.
I have seen a failure of NewObjectA.return (seeing zero as return value)
against a build with 4.6.3. So that might explain why the test was
wrong before and we hadn't noticed.

I haven't had time to analyze what the old GCC did wrong to cause the
test failure, but by default, with a modern GCC, all jstaptest.pl tests
should now all pass.

Cheers,

Mark