[
https://issues.apache.org/jira/browse/KUDU-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194050#comment-16194050
]
Adar Dembo commented on KUDU-2167:
----------------------------------
I did some git spelunking and AFAICT the client-side code has always been
vulnerable to this, and the server-side code was changed to omit the 'data'
field when there's no data in commit 822f6b6. That commit was part of the first
Kudu release, so it's also more or less "since forever".
> C++ client crashes when server filters out all data in a scan RPC
> -----------------------------------------------------------------
>
> Key: KUDU-2167
> URL: https://issues.apache.org/jira/browse/KUDU-2167
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: 1.3.1, 1.4.0, 1.5.0, 1.2.1
> Reporter: Adar Dembo
> Assignee: Adar Dembo
> Priority: Critical
>
> (this may affect older versions too; I only checked as far back as 1.4.0).
> A crash like this was observed in a test cluster:
> {noformat}
> *** Aborted at 1507079547 (unix time) try "date -d @1507079547" if you are
> using GNU date ***
> PC: @ 0x7f41942410ad std::swap<>()
> *** SIGSEGV (@0x18) received by PID 12187 (TID 0x7f418d067840) from PID 24;
> stack trace: ***
> @ 0x7f4192d82390 (unknown)
> @ 0x7f41942410ad std::swap<>()
> @ 0x7f419120b51d kudu::RowwiseRowBlockPB::InternalSwap()
> @ 0x7f419120b4ed kudu::RowwiseRowBlockPB::Swap()
> @ 0x7f419400cf15 kudu::client::KuduScanBatch::Data::Reset()
> @ 0x7f4193f928f2 kudu::client::KuduScanner::NextBatch()
> {noformat}
> I've tracked this down to the client scanner code which assumes that if the
> previous scan request indicated that more results await, the next scan
> request must return data. There's at least one case where that isn't true:
> when the server filters out all data in the next scan request due to a
> predicate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
