Myrna van Lunteren wrote:
Hi,
I see fairly regular failures caused by a failure in cleaning up
extinout/t1.dat in the nightly tests run at IBM, see for example:
http://people.apache.org/~fuzzylogic/derby_test_results/main/derbymain/testSummary-609084.html
I am wondering if anyone has any suggestions on how to debug or even
solve these...?
Since it seems to be failing only on Windows, it is likely caused by
Derby having an open handle to that file, which would prevent it from
being deleted om Windows. The problematic subtest is run twice (embedded
and networkserver). The test fails as in DERBY-3068 if an open handle is
kept after the first run of the subtest and the second run stumbles into
this when it first tries to export to that same file. The test fails as
in DERBY-2636 if an open handle is kept after either of the subtests
when the DropDatabaseSetup tries to clean up. Since it happens when the
second run of the subtest first tries to access the file again, I am
guessing the problem is triggered by something in the subtest that
happens after the last export statement to that file, or that statement
would have failed for the same reason. After the last export using that
file there is a number of import statements using that file that are
expected to fail, I am guessing one or more of these can trigger the
problem or it is the last export.
One way to debug (as the failure seems easily reproducible) would be to
just remove the import statements at the end of the subtest
(testImportExportProcedureNegative) and see if that removes the problem,
and then try to narrow down exactly what statement triggers the handle
leak. That might get you close enough to start looking at why that
leaves an open file handle when running on some jvms.
Vemund
