(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:
*** 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()
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.