You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Tim (Jira)" <ji...@apache.org> on 2019/12/03 17:56:00 UTC
[jira] [Updated] (VFS-748) TarProvider Incorrectly marks file
IMAGINARY after garbage collection with weakRefFilesCache
[ 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)