[
https://issues.apache.org/jira/browse/ARROW-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SIDDHARTH TEOTIA updated ARROW-1478:
------------------------------------
Summary: [JAVA]: clear should release the buffer only if the buffer is not
NULL (was: clear should release the buffer only if the buffer is not NULL)
> [JAVA]: clear should release the buffer only if the buffer is not NULL
> ----------------------------------------------------------------------
>
> Key: ARROW-1478
> URL: https://issues.apache.org/jira/browse/ARROW-1478
> Project: Apache Arrow
> Issue Type: Bug
> Components: Java - Vectors
> Reporter: SIDDHARTH TEOTIA
> Assignee: SIDDHARTH TEOTIA
>
> In some cases we use a fake allocator in Dremio for the purpose of field
> materialization only. The buffers of the underlying vectors are not
> allocated. Fake allocator is a simple implementation of BufferAllocator
> interface where almost every method throws UnsupportedOperation exception and
> methods like getEmpty() return NULL.
> It is more like a pass-through mechanism that allows us to be able to
> instantiate a vector using a non-functional allocator since the constructors
> in vector code don't allow for the allocator itself to be NULL.
> Portions of code where we have this scenario are generic in nature and so
> have typical methods like close() / clear() which underneath invoke the
> corresponding methods on vectors.
> The clear() method in BaseDataValueVector releases the data buffer without
> checking if the buffer is NULL and that's where callers hit NPE.
> We don't see such problems in Arrow unit tests. My guess is that when a
> vector is instantiated, the buffer is still probably a valid reference
> returned through allocator.getEmpty() call in the constructor of
> BaseDataValueVector.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
