[ 
https://issues.apache.org/jira/browse/JENA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081705#comment-13081705
 ] 

Simon Helsen commented on JENA-91:
----------------------------------

OK, I installed the latest TDB () and my tests seem to run ok now, but with the 
expected messages from the check:

11:02:55,647 [jazz.jfs.resuming.indexer.internal.triple] ERROR TDB              
                                   - ObjectFile.read(61)[372][372]: Impossibly 
large object : 1869495647 bytes
....
11:03:21,691 [jazz.jfs.resuming.indexer.jfs_tests_default_consumer_name.triple] 
ERROR TDB                                                 - 
ObjectFile.read(61)[466][466]: Impossibly large object : 893809995 bytes

etc.

The pattern seems quite similar most of the time. I wonder if the check makes 
sense like this. These are the different values I see whenever the exception 
occurrs. The location is *always* 61 it seems and the last 2 values are 
identical.

ObjectFile.read(61)[466][466]
ObjectFile.read(61)[422][422]
ObjectFile.read(61)[2863][2863]
ObjectFile.read(61)[423][423]
ObjectFile.read(61)[2865][2865]
ObjectFile.read(61)[425][425]
ObjectFile.read(61)[2903][2903]
ObjectFile.read(61)[416][416]
ObjectFile.read(61)[429][429]
ObjectFile.read(61)[377][377]
ObjectFile.read(61)[365][365]


> extremely large buffer is being created in ObjectFileStorage
> ------------------------------------------------------------
>
>                 Key: JENA-91
>                 URL: https://issues.apache.org/jira/browse/JENA-91
>             Project: Jena
>          Issue Type: Bug
>          Components: TDB
>         Environment: Windows (and I presume any little endian system)
>            Reporter: Simon Helsen
>            Priority: Critical
>
> I tried to debug the OME and check why a bytebuffer is causing my native 
> memory to explode in almost no time. It all seems to happen in this bit of 
> code in com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage (lines 243 
> onwards)
>   // No - it's in the underlying file storage.
>         lengthBuffer.clear() ;
>         int x = file.read(lengthBuffer, loc) ;
>         if ( x != 4 )
>             throw new 
> FileException("ObjectFile.read("+loc+")["+filesize+"]["+file.size()+"]: 
> Failed to read the length : got "+x+" bytes") ;
>         int len = lengthBuffer.getInt(0) ;
>         ByteBuffer bb = ByteBuffer.allocate(len) ;
> My debugger shows that x==4. It also shows the lengthBuffer has the following 
> content: [111, 110, 61, 95]. This amounts to the value of len=1869495647, 
> which is rather a lot :-) Obviously, the next statement (ByteBuffer.allocate) 
> causes the OME.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to