[
https://issues.apache.org/jira/browse/IMPALA-9415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042246#comment-17042246
]
Tim Armstrong commented on IMPALA-9415:
---------------------------------------
capacity() doesn't account for malloc overhead either, so it's not even
strictly accurate. We could probably just use size() or round up or pad size()
to account for overhead if we wanted to be conservative.
> DCHECK in ClientRequestState::FetchRowsInternal when using GCC7 with the new
> ABI
> --------------------------------------------------------------------------------
>
> Key: IMPALA-9415
> URL: https://issues.apache.org/jira/browse/IMPALA-9415
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 3.4.0
> Reporter: Joe McDonnell
> Priority: Major
>
> ClientRequestState::FetchRowsInternal is hitting a DCHECK when running
> hs2/test_fetch_first.py::TestFetchFirst::test_query_stmts_v1 and other hs2
> tests:
> {noformat}
> F0221 14:27:15.796236 6013 client-request-state.cc:1090] Check failed:
> before + delta_bytes >= after (14270 vs. 14340) Combined result sets consume
> more memory than both individually (before: 0, delta_bytes: 14270, after:
> 14340){noformat}
> This is firing because the size of a row increases when it is copied into the
> result set. The size increases because the capacity of the string is
> increasing when it is copied. In the row passed in, one field has a string
> with size=29, capacity=29. After it is copied into the result set, it has
> size=29, capacity=30. Since we count the string memory usage based on
> capacity, the memory usage has gone up.
> In general, the behavior of capacity() is unspecified, and we can't rely on a
> specific semantic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
