[
https://issues.apache.org/jira/browse/IO-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-161.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.5)
2.0
Assignee: Niall Pemberton
I have copied the code from BeanUtils MemoryLeakTestCase to try and force
garbage collection. Hopefully that will be more successful in ytour
environment, but if not then it should now throw an exception rather than
hanging
http://svn.apache.org/viewvc?view=rev&revision=723153
> FileCleaningTrackerTestCase hangs
> ---------------------------------
>
> Key: IO-161
> URL: https://issues.apache.org/jira/browse/IO-161
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.4
> Environment: Linux sliver.usr.dsi.unimi.it 2.6.22.14-72.fc6 #1 SMP
> Wed Nov 21 15:12:59 EST 2007 i686 i686 i386 GNU/Linux
> java version "1.5.0_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing)
> Reporter: Sebastiano Vigna
> Assignee: Niall Pemberton
> Fix For: 2.0
>
>
> The following code in FileCleaningTrackerTestCase never exits, hanging the
> whole compilation/testing process:
> private void waitUntilTrackCount() {
> while (theInstance.getTrackCount() != 0) {
> int total = 0;
> while (theInstance.getTrackCount() != 0) {
> byte[] b = new byte[1024 * 1024];
> b[0] = (byte) System.currentTimeMillis();
> total = total + b[0];
> System.gc();
> }
> }
> }
> It is clear that in theory this code might loop forever, as the allocation of
> the byte arrays might never unleash a garbage collection complete enough to
> deallocate all marker objects, so to bring the track count to zero. Believe
> me, it's not only theory :).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
