[Bug] Segfault in BaseCommand::ByteSizeLong when closing a partitioned producer
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- cpp
- Área
- backend, distributed-systems
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C++
- Estrellas
- 72
- Forks
- 93
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/pulsar-client-cpp
-
Dificultad 3/5 Medio día Aptitud para principiantes 62/100
apache/pulsar-client-cpp#623 ·
-
[Bug] MessageTest fails to build with GCC 15.3.0 and 16.2.1 (-Werror=stringop-truncation)Posiblemente ocupada @davlgd la tomó hace 3 días. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 25/100
apache/pulsar-client-cpp#621 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
apache/pulsar-client-cpp#620 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
apache/pulsar-client-cpp#618 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
apache/pulsar-client-cpp#617 ·
Todos los issues de apache/pulsar-client-cpp
Issues similares
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
EchoTools/nevr-runtime#2042 ·
Los mantenedores suelen responder en 1 día
-
Download size and speed show scientific notation between 1000 and 1023 unitsPosiblemente ocupada @RaphaelFakhri la tomó hoy. Abierto
Dificultad 2/5 Menos de una hora Aptitud para principiantes 88/100
kiwix/kiwix-desktop#1570 ·
Los mantenedores suelen responder en 1 día
-
Device Request
Dificultad 2/5 Medio día Aptitud para principiantes 62/100
dresden-elektronik/deconz-rest-plugin#8686 ·
Los mantenedores suelen responder en 1 día
-
nixos/noctalia-greeter: greeter finds no sessions (session dirs not passed via XDG_DATA_DIRS)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aminya/project_options#303 ·