[Bug]: iOS abort in geocoding_darwin Pigeon reply encoding after registrar deallocation
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 49/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Área
- backend-api-design, mobile
Línea de trabajo
Read GeocodingLibrary.g.swift around line 609 and GeocodingDarwinPlugin.swift around lines 27–30, then trace the completion handlers for all three asynchronous geocoding methods. Start by checking how detach and pending replies interact; the issue describes a source-backed hypothesis but no deterministic reproducer. Done means completions remain safe across teardown while normal success and error replies still work when attached.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Please check the following before submitting a new issue.
- I have searched the existing issues.
- I have carefully read the documentation and verified I have added the required platform specific configuration.
Please select affected platform(s)
- Android
- iOS
Steps to reproduce
We observed a native iOS crash during completion of an asynchronous geocoding request. A sanitized symbolicated stack is attached.
We do not yet have a deterministic reproducer. The app was in the background when the crash occurred; this does not establish that backgrounding caused engine teardown.
A suspected lifecycle sequence to investigate:
- Start a geocoding request and delay its completion.
- Detach the plugin from the Flutter engine.
- Deliver the pending completion.
- Check whether reply encoding accesses the released Pigeon registrar.
This sequence is a source-backed hypothesis, not a confirmed reproduction.
Expected results
Pending geocoding completions should remain safe across plugin/engine teardown. After detach, they should not encode or send replies through a released registrar or detached engine.
Normal success and error replies should continue working while attached.
Actual results
The process terminates with EXC_CRASH (SIGABRT).
Relevant stack:
swift::swift_abortRetainUnowned
swift_unownedRetainStrong
GeocodingLibraryPigeonInternalProxyApiCodecReaderWriter.writer(with:)
GeocodingLibrary.g.swift:609
FlutterStandardMessageCodec encode:
FlutterBasicMessageChannel ... reply
PigeonApiCLGeocoder.setUpMessageHandlers(...)
CLGeocoderProxyApiDelegate.geocodeAddressString(...) completion
The immediate failure is an expired Swift unowned reference during reply encoding.
Source inspection shows:
- The codec reader/writer holds an unowned pigeonRegistrar.
- detachFromEngine sets ignoreCallsToDart, tears down handlers, then releases proxyApiRegistrar.
- Pending geocoding completion handlers invoke reply without checking registrar availability or detach state.
Relevant upstream source:
https://github.com/Baseflow/flutter-geocoding/blob/cd7c13c84de45291c21ed5930f3d0941706d302a/geocoding_darwin/darwin/geocoding_darwin/Sources/geocoding_darwin/Geocoding/GeocodingLibrary.g.swift#L608-L609
A possible fix is to guard pending completions against registrar release/detach and keep the registrar alive during reply encoding, with callback delivery serialized against teardown. All three asynchronous geocoding methods need equivalent handling.
The precise event that released the registrar in this incident remains unknown.
Code sample
The application retains a Geocoding instance and calls:
final geocoding = Geocoding();
final placemarks = await geocoding.placemarkFromCoordinates(
latitude,
longitude,
);
This usage alone is not a reproducer. The symbolicated stack names geocodeAddressString despite the application's reverse-geocoding call; that discrepancy remains unresolved.
Screenshots or video
Screenshots or video demonstration
[Upload media here]
Version
geocoding 5.0.0 geocoding_darwin 1.0.3 iOS, ARM64
Flutter Doctor output
Not available
- Lenguaje dominante
- Dart
- Estrellas
- 153
- Forks
- 92
- Merge medio
- 7 d 21 h
- PR fusionados (30 d)
- 3
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 Baseflow/flutter-geocoding
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Baseflow/flutter-geocoding#324 ·
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 84/100
Baseflow/flutter-geocoding#311 · 2 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Baseflow/flutter-geocoding#309 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
Baseflow/flutter-geocoding#287 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Baseflow/flutter-geocoding#286 · 2 comentarios ·
Todos los issues de Baseflow/flutter-geocoding
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
bannzai/medicalarm#478 ·
Los mantenedores suelen responder en 1 día
-
genkit_anthropic: responses with an empty or unknown usage.service_tier fail with FormatException: Unknown ServiceTierPosiblemente ocupada @kenzieschmoll la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
genkit-ai/genkit-dart#686 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
aaronified/fluenough#918 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
VeryGoodOpenSource/very_good_analysis#255 ·
Los mantenedores suelen responder en 1 día