[Bug] Segfault in BaseCommand::ByteSizeLong when closing a partitioned producer
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 48/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- cpp
研究方向
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.
由索引模型根據 Issue 內容生成。
描述
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.
- 主要語言
- C++
- 星號
- 72
- 分支
- 93
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
apache/pulsar-client-cpp 的其他 Issue
-
難度 3/5 半天 新手友好度 62/100
apache/pulsar-client-cpp#623 ·
-
[Bug] MessageTest fails to build with GCC 15.3.0 and 16.2.1 (-Werror=stringop-truncation)可能已有人在做 @davlgd 於 4 天前認領。 未關閉
難度 1/5 1 小時以內 新手友好度 25/100
apache/pulsar-client-cpp#621 ·
-
難度 4/5 3-5 天 新手友好度 55/100
apache/pulsar-client-cpp#620 ·
-
難度 4/5 3-5 天 新手友好度 20/100
apache/pulsar-client-cpp#618 ·
-
難度 4/5 3-5 天 新手友好度 30/100
apache/pulsar-client-cpp#617 ·
查看 apache/pulsar-client-cpp 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 82/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 3 天內回覆
-
Bug
難度 2/5 1-3 小時 新手友好度 68/100
SCIInstitute/SCIRun#2909 ·
維護者通常 2 天內回覆
-
bug libcudf
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 2 天內回覆
-
Triage: Needed
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 2 天內回覆