"David W. Van Couvering" <[EMAIL PROTECTED]> writes: > I got some test failures in derbynetclient mats, so I checked the > tinderbox. We have quite a number of failures on the latest revision > that ran tests, 370061, running on Solaris 10 x86: > > http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-370061.html > > derbylang: 1 failure > derbytools: 1 failure > encryptionBlowfish: 1 failure > i18nTest: 1 failure > jdbcapi: 1 failure > derbynetclientmats: 3 failures > derbynetmats: 2 failures > encryptionAll: 2 failures > encryptoin: 1 failure > > derbyall: 12 failures > > This seems a bit much; it's hard for a developer to know if their own > changes are valid as you have to sift through all the existing > failures. The last Solaris 10 x86 regression test run on revision > 369861 had only 2 failures. > > Looking at the derbyall history, at least on XP it seems to be getting > worse and worse (from 7 failures on 1/6 to 12 failures on 1/17). On > Solaris 10 it's gone from 1 failure to 5 failures, while on Linux it's > stayed steady. > > Can those of us who have checked in/contributed patches lately please > look at the failures and see if you recognize what might be causing > them?
It is not checked in lately, but my patch to DERBY-23 (checked in 21st of September) is causing some of these failures (not limited to one test). Everytime you see a diff that just contains lines looking like this one, blame me: > Exception in thread "derby.rawStoreDaemon" java.lang.NullPointerException Rolling back parts of the DERBY-23 patch will fix these test failures (which as far as I can tell are cosmetic), but it will also reintroduce a memory leak. The long term solution is somehow to catch and handle the NullPointerExceptions. I'm not sure what's the best short term solution, rolling back parts of the patch or simply ignoring the occasional derbyall failures. -- Knut Anders
