[jira] [Updated] (VFS-748) TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (VFS-748) TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/VFS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim updated VFS-748:
--------------------
    Description:
A Tar FileObject becomes unusable once it is removed from the filesCache.  The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed.

 

The following code snippet will repeatedly access the the tarball until garbage collection occurs.  When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that incorrectly marks the file as "IMAGINARY".  All subsequent access to this file is are not possible in the VM.

 

Output from the class provided looks like this....

97
 98
 99
 100
 tgz:[file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/] did not exist

 

The number of successful iterations may vary depending upon the behavior of the GC.

Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true.  The stack trace for this appears below. 

at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320)   - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300)   at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82)   - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711)   at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648)

  was:
A Tar FileObject becomes unusable once it is removed from the filesCache.  The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed.

 

The following code snippet will repeatedly access the the tarball until garbage collection occurs.  When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that is incorrectly marks the file as "IMAGINARY".  All subsequent access to this file is are not possible in the VM.

 

Output from the class provided looks like this....

97
98
99
100
tgz:file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/ did not exist

 

The number of successful iterations may vary depending upon the behavior of the GC.

Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true.  The stack trace for this appears below. 

at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320)   - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300)   at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82)   - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711)   at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648)


> TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache
> --------------------------------------------------------------------------------------------
>
>                 Key: VFS-748
>                 URL: https://issues.apache.org/jira/browse/VFS-748
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.2
>         Environment: commons-vfs2.2.jar
> commons-compress-1.18.jar
>            Reporter: Tim
>            Priority: Major
>         Attachments: TarBug.java, test.tar.gz
>
>
> A Tar FileObject becomes unusable once it is removed from the filesCache.  The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed.
>  
> The following code snippet will repeatedly access the the tarball until garbage collection occurs.  When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that incorrectly marks the file as "IMAGINARY".  All subsequent access to this file is are not possible in the VM.
>  
> Output from the class provided looks like this....
> 97
>  98
>  99
>  100
>  tgz:[file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/] did not exist
>  
> The number of successful iterations may vary depending upon the behavior of the GC.
> Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true.  The stack trace for this appears below. 
> at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320)   - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300)   at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82)   - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711)   at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)