Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

isImplementedInClass leaks the losing sample instance on re-entrant or racing cache population

Aberta
  • Algo errado?
#459 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
cpp, objective-c
Domínio
mobile-dev

Direção de pesquisa

Comece em NativeScript/runtime/Metadata.mm, em MethodMeta::isImplementedInClass e no comentário que aponta para esta issue; acompanhe o preenchimento de sampleInstances, o uso do mutex e o comportamento re-entrant de alloc. O trabalho estará concluído quando as sample instances abandonadas durante um preenchimento re-entrant ou concorrente forem eliminadas sem causar deadlocks, liberações inseguras ou retenção perpétua intencional.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Problem

MethodMeta::isImplementedInClass (NativeScript/runtime/Metadata.mm) keeps a process-wide cache of [klass alloc]-created sample instances used to answer respondsToSelector: for classes whose alloc returns a different class or which forward messages. The cache is populated like this:

  1. [klass alloc] runs outside the mutex — deliberately, because alloc can trigger +initialize, which may run arbitrary code that re-enters this method (holding the lock would deadlock).
  2. The lock is then taken and sampleInstances.emplace(klass, instance) inserts.

When the emplace loses — the re-entrant call already populated the entry for the same class, or another thread raced — the freshly allocated instance is abandoned: one leaked object per lost race (Instruments shows these as e.g. a leaked UIAlertView / NSURLSessionConfiguration attributed to isImplementedInClass). The count varies run to run since it is timing-dependent.

Why the obvious fixes don't work

  • Releasing the loser is unsafe: the instance is alloc'd but never init'd, so -release runs -dealloc against zero-filled ivars of an arbitrary framework class, on whatever thread the probe ran on (it demonstrably runs on worker threads). Benign for most classes, but a -dealloc that does CFRelease/dispatch_release on a zero ivar traps, and UIKit teardown off the main thread is asserting territory.
  • Holding the lock across alloc deadlocks via the +initialize re-entry described above.
  • Parking losers in a static container merely converts the unreachable leak into intentional perpetual retention — it silences Instruments without reclaiming anything (tried and reverted in #458).

Potential solutions

  • A re-entrancy-aware locking scheme (recursive mutex, or a reader/writer arrangement) so the populate path can be made atomic with respect to re-entrant probes without deadlocking through +initialize.
  • Reuse already-alloc-ed objects: when a sample for that Class is requested (or something else calls [thatClass alloc] through the runtime), hand out / consume the cached instance instead of allocating another, so a losing instance gets used rather than abandoned.

The leak site carries a comment pointing at this issue.

Linguagem predominante
JavaScript
Estrelas
150
Forks
44
Merge médio
1d 8h
PRs com merge (30d)
8

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NativeScript/ios

Todas as issues de NativeScript/ios

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.