db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: Testing 10.2.0.2 Snapshot
Date Wed, 14 Jun 2006 20:36:05 GMT
On 6/5/06, Ole Solberg <Ole.Solberg@sun.com> wrote:
> > On 6/5/06, Ole Solberg <Ole.Solberg@sun.com> wrote:
> >
> >> Derbyall
> >> ********
> >> Results from our testing on the 10.2.0.2 snapshots are now available at
> >> http://www.multinet.no/~solberg/public/Apache/index.html#TenTwoZeroSnapshots
> >>

I ran derbyall with this 10.2.0.2 snapshot on Linux with a 64bit IBM
jvm, versions 1.4.2 and 1.5. With 1.5, I ran once in the default mode,
and once with the jit always 'on' (-Xjit:count=0).

Looking at our nightly testing with 32 bit jvms on windows it does not
seem likely additional trouble will be found with the updated
snapshot, so I'm not redoing that testing, but posting the findings
here.

Issues encountered were either jvm or test harness related (with one
possible exception):
================
ibm.1.4.2
- with ibm1.4.2, minor issue regarding wording of security permissions
errors; 'Access' vs. 'access' in Sun jvms. I've been told this is a
known issue with the jvm vendor. We could add sed-ing to the tests
affected so this doesn't show up anymore...
- hang in unit/cacheService.unit with ibm1.4.2 64 bit jvm only
    I need to further analyze this.

ibm1.5
- IBM jvm 1.5. JIT causes incorrect results in calculations, leading
to very large numbers. This can be seen for instance in the results
from runtimestatistics (see also DERBY-1221) or result in too big
identity column numbers (see DERBY-1327).
   The issue has been reported to the jvm team and preliminary info
indicates both these behaviors have the same underlying jit problem.
    This issue is not limited to the 64bit jvm.
- derbynetmats testing fails because of an extra jvm line getting
generated when calling the db2jcc code: > JVMJ9VM034E jvmri requires
trace engine: run with -Xtrace flag
    This issue has been reported to the jvm vendor/developers. This
behavior is specific to 64 bit jvms.
- IBM 1.5. jvm is more aggressive in garbage collecting, resulting in
fewer error conditions encountered. This has been reported to the jvm
vendor/developers.

Env Details:
=========
host: 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:56:28 EST 2006 x86_64 x86_64
x86_64 GNU/Linux
jvm:
1.4.2:
-----------------------
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 2.2)
IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142-20050609
(JIT enabled)
J9VM - 20050524_1742_LHdSMr
JIT  - r7_level20050518_1803)
-----------------------
1.5:
-----------------------
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20060511 (SR2))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JI
T enabled)
J9VM - 20060501_06428_lHdSMR
JIT  - 20060428_1800_r8
GC   - 20060501_AA)
JCL  - 20060511a
------------------------

Failures => explanations:
===========
ibm142:
-----------------------
- derbyall/derbyall.fail:lang/dcl.sql - jvm message diff (Access
denied vs. expected access denied) known.
- derbyall/derbyall.fail:lang/predicatePushdown.sql - different
scores, different paths... Diffs look reasonable. Test harness cannot
currently handle this kind of ok diffing.
- derbyall/derbyall.fail:tools/ijConnName.sql - timing diff of 'ERROR
08001: No suitable driver'. ok. Test harness cannot currently handle
this kind of ok diffing.
- derbyall/derbyall.fail:unit/cacheService.unit - hang/timeout - .... ????
- derbyall/demo/demo.fail:demo/RunClassPathTester.java - (Access
denied vs. expected access denied) known
- derbyall/derbynetclientmats/derbynetmats.fail:derbynet/checkSecMgr.java
(Access denied vs. expected access denied) known
- 15 derbynetmats tests fail because of extra jvm line in output from
jcc driver.

ibm1.5. with default jit operation:
---------------------------------------------
runtimestatistics :
- derbyall/storeall/storemats.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/encryptionAll.fail:store/access.sql
- derbyall/encryptionAll/storemats.fail:store/access.sql
- derbyall/derbyall.fail:lang/subqueryFlattening.sql
- derbyall/derbyall.fail:lang/predicatePushdown.sql
- derbyall/derbyall.fail:lang/ddlTableLockMode.sql
- derbyall/derbyall.fail:lang/outerjoin.sql
- derbyall/derbyall.fail:lang/staleplans.sql
- derbyall/derbyall.fail:lang/wisconsin.java
- derbyall/derbynetmats/derbynetmats.fail:lang/optimizerOverrides.sql
- derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java
- derbyall/derbynetclientmats/derbynetmats.fail:lang/wisconsin.java
identity column
- derbyall/storeall/storeall.fail:store/bug3498.sql
- derbyall/derbynetclientmats/derbynetmats.fail:tools/ieptests.sql
- derbyall/derbyall.fail:tools/dblook_test.java

other known:
- derbyall/derbyall.fail:lang/procedure.java - testImplicitClose
intermittently fails...related to increased garbage collection in jvm.
- derbyall/derbyall.fail:jdbcapi/setTransactionIsolation.java -
garbage collection problem.

ibm1.5. with immediate jit activation: (-Xjit:count=0)
----------------------------------------------------
failures because of runtimestatistics long numbers:
derbyall/derbyall.fail:lang/distinct.sql
derbyall/derbyall.fail:lang/orderbyElimination.sql
derbyall/derbyall.fail:lang/desc_index.sql
derbyall/derbyall.fail:lang/aggregateOptimization.sql
derbyall/derbyall.fail:lang/distinctElimination.sql
derbyall/derbyall.fail:lang/predicatesIntoViews.sql
derbyall/derbyall.fail:lang/distinctFiltering.sql
derbyall/derbyall.fail:lang/specjPlans.sql
derbyall/derbyall.fail:lang/subquery.sql
derbyall/derbyall.fail:lang/dynamicLikeOptimization.sql
derbyall/derbynetclientmats/derbynetmats.fail:lang/optimizerOverrides.sql
plus those that also failed with normal jit operation

because of identity column large numbers:
derbyall/derbyall.fail:lang/scrollCursors1.sql
derbyall/derbyall.fail:lang/holdCursorJava.java
derbyall/derbyall.fail:jdbcapi/checkDataSource30.java
derbyall/derbyall.fail:jdbcapi/checkDataSource.java
derbyall/derbyall.fail:lang/modifyColumn.sql
derbyall/derbyall.fail:lang/syscat.sql
derbyall/derbyall.fail:jdbcapi/odbc_metadata.java
derbyall/derbyall.fail:lang/autoincrement.sql
derbyall/derbyall.fail:jdbcapi/metadata.java
derbyall/derbyall.fail:tools/ieptests.sql
derbyall/derbyall.fail:jdbcapi/characterStreams.java
derbyall/derbynetmats/derbynetmats.fail:lang/scrollCursors1.sql
derbyall/derbynetmats/derbynetmats.fail:lang/syscat.sql
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
derbyall/derbynetmats/derbynetmats.fail:tools/ieptests.sql
derbyall/demo/demo.fail:demo/checkToursDB.java
derbyall/derbynetclientmats/derbynetmats.fail:lang/scrollCursors1.sql
derbyall/derbynetclientmats/derbynetmats.fail:lang/holdCursorJava.java
derbyall/derbyall.fail:tools/dblook_test.java
derbyall/derbynetmats/derbynetmats.fail:derbynet/dblook_test_net.java
derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dblook_test_net.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/checkDataSource30.java
derbyall/derbynetclientmats/derbynetmats.fail:lang/syscat.sql
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbyall/derbynetclientmats/derbynetclientmats.fail:jdbcapi/checkDataSource.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/metadata.java
plus those that failed with normal jit operation.

Finally, note that it was not possible to successfully run the upgrade
suite with this jit setting because the test harness currently cannot
pass 2 jvmflags (see DERBY-1091), and we'd need to pass both
derbyTesting.jar.path and -Xjit:count=0.

===============

Mime
View raw message