You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sending a record batch > 2GiB, the server will segfault. Although Flight checks for this case and returns an error, it turns out that gRPC always tries to increment the refcount of the result buffer whether the serialization handler returned successfully or not:
// From gRPC 1.36
Status CallOpSendMessage::SendMessagePtr(const M* message,
WriteOptions options) {
msg_ = message;
write_options_ = options;
// Store the serializer for later since we have access to the message
serializer_ = [this](constvoid* message) {
bool own_buf;
// TODO(vjpai): Remove the void below when possible// The void in the template parameter below should not be needed// (since it should be implicit) but is needed due to an observed// difference in behavior between clang and gcc for certain internal users
Status result = SerializationTraits<M, void>::Serialize(
*static_cast<const M*>(message), send_buf_.bbuf_ptr(), &own_buf);
if (!own_buf) {
// XXX(lidavidm): This should perhaps check result.ok(), or Serialize should// unconditionally initialize send_buf_
send_buf_.Duplicate();
}
return result;
};
returnStatus();
}
Hence when Flight returns an error without initializing the buffer, we get a segfault.
David Li / @lidavidm:
Now this is annoying: gRPC fails an assertion later on anyways if the serialization handler raises an error. For Flight to do what it intends, it needs to move the check up. But then we may want to move the computation of the body size up as well, or we'll be duplicating work.
When sending a record batch > 2GiB, the server will segfault. Although Flight checks for this case and returns an error, it turns out that gRPC always tries to increment the refcount of the result buffer whether the serialization handler returned successfully or not:
Hence when Flight returns an error without initializing the buffer, we get a segfault.
Originally reported on StackOverflow: https://stackoverflow.com/questions/68230146/pyarrow-flight-do-get-segfault-when-pandas-dataframe-over-3gb
Reporter: David Li / @lidavidm
Assignee: David Li / @lidavidm
PRs and other links:
Note: This issue was originally created as ARROW-13253. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: