[Bug] Segfault in BaseCommand::ByteSizeLong when closing a partitioned producer
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp
- Lĩnh vực
- backend, distributed-systems
Hướng nghiên cứu
Read lib/PartitionedProducerImpl.cc at runPartitionUpdateTask and getPartitionMetadata, then inspect lib/Commands.cc and the other Commands::new* helpers for the static BaseCommand pattern. Trace how timer cancellation and producer shutdown interact, and run the partitioned producer shutdown tests. Done when closing a partitioned producer and client no longer triggers the reported shutdown segfault.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Version
pulsar-client-cpp 3.4.2. The same two code paths are still present on current master:
- lib/Commands.cc: Commands::newPartitionMetadataRequest keeps a function-local static BaseCommand
- lib/PartitionedProducerImpl.cc: runPartitionUpdateTask ignores the timer error_code
Minimal reproduce step
- Create a client with the default partitionsUpdateInterval (60 seconds).
- createProducer on a partitioned topic (getPartitions() > 0), so the implementation is PartitionedProducerImpl and runPartitionUpdateTask is armed.
- On process shutdown call producer.close() and then client.close().
producer.close() cancels partitionsUpdateTimer_. The wait handler still runs because it does not check ec:
partitionsUpdateTimer_->async_wait([weakSelf](const ASIO_ERROR& ec) {
auto self = weakSelf.lock();
if (self) {
self->getPartitionMetadata();
}
});
getPartitionMetadata() does not check that the producer is closing. It sends PARTITIONED_METADATA through Commands::newPartitionMetadataRequest, which serializes a function-local static protobuf message:
SharedBuffer Commands::newPartitionMetadataRequest(const std::string& topic, uint64_t requestId) {
static BaseCommand cmd;
static std::mutex mutex;
std::lock_guard<std::mutex> lock(mutex);
// ...
SharedBuffer buffer = writeMessageWithSize(cmd); // cmd.ByteSize() / ByteSizeLong()
}
client.close() then shuts the lookup service down and joins executor threads with a short timeout. The listener thread can still be inside ByteSizeLong() while that static BaseCommand is being destroyed. Destruction of the statics does not take mutex.
Workaround: clientConfiguration.setPartititionsUpdateInterval(0) before creating the partitioned producer. The timer is not created when the interval is 0. New partitions are then picked up only after the producer is recreated.
What did you expect to see?
producer.close() / client.close() stop the partition-update task and return without a segmentation fault.
What did you see instead?
Intermittent segfault on the Pulsar listener thread during shutdown:
#0 ??
#1 pulsar::proto::BaseCommand::ByteSizeLong() const
#2 pulsar::Commands::writeMessageWithSize(pulsar::proto::BaseCommand const&)
#3 pulsar::Commands::newPartitionMetadataRequest(...)
#4 pulsar::ClientConnection::newPartitionedMetadataLookup(...)
#5 pulsar::BinaryProtoLookupService::sendPartitionMetadataLookupRequest(...)
#6 std::_Function_handler<... BinaryProtoLookupService::sendPartitionMetadataLookupRequest ...>
#7 pulsar::BinaryProtoLookupService::getPartitionMetadataAsync(...)
#8 pulsar::RetryableLookupService::getPartitionMetadataAsync(...)::{lambda}
#9 pulsar::RetryableOperation<...>::runImpl(...)
#10 pulsar::RetryableOperation<...>::run()
#11 pulsar::RetryableOperationCache<...>::run(...)
#12 pulsar::RetryableLookupService::getPartitionMetadataAsync(...)
#13 pulsar::PartitionedProducerImpl::getPartitionMetadata()
#14 boost::asio::detail::wait_handler<PartitionedProducerImpl::runPartitionUpdateTask()::{lambda...}>::do_complete(...)
#15 boost::asio::detail::scheduler::run(...)
#16 pulsar::ExecutorService::start()::{lambda}::operator()
#17 start_thread
#0 is a jump through an invalid address inside protobuf ByteSizeLong() of that static BaseCommand.
Anything else?
Suggested fix:
- In runPartitionUpdateTask, return when ec is set (operation_aborted).
- In getPartitionMetadata, return unless state_ == Ready.
- Stop using function-local static BaseCommand in Commands.cc. Use an automatic BaseCommand so shutdown cannot destroy the message while another thread is in ByteSizeLong(). The same static pattern is used by the other Commands::new* helpers.
A non-partitioned producer does not hit this path. PartitionedProducerImpl is created only when partitionMetadata->getPartitions() > 0.
- Ngôn ngữ chính
- C++
- Star
- 72
- Fork
- 93
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/pulsar-client-cpp
-
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 62/100
apache/pulsar-client-cpp#623 ·
-
[Bug] MessageTest fails to build with GCC 15.3.0 and 16.2.1 (-Werror=stringop-truncation)Có thể đã có người làm @davlgd đã nhận 4 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 25/100
apache/pulsar-client-cpp#621 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
apache/pulsar-client-cpp#620 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 20/100
apache/pulsar-client-cpp#618 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
apache/pulsar-client-cpp#617 ·
Tất cả issue của apache/pulsar-client-cpp
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Segfault when all runs of a Complexity() benchmark are skippedCó thể đã có người làm @nitanshnagpal đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Code: Performance
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
CrimsonCrossBunker/Cataclysm-Cleanwater-Bomb#1167 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
meshcore-dev/MeshCore#3760 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày