[Bug]: iOS abort in geocoding_darwin Pigeon reply encoding after registrar deallocation
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 49/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Domaine
- backend-api-design, mobile
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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
- Langage dominant
- Dart
- Étoiles
- 153
- Forks
- 92
- Merge moyen
- 7 j 21 h
- PR mergées (30 j)
- 3
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de Baseflow/flutter-geocoding
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
Baseflow/flutter-geocoding#324 ·
-
Difficulté 1/5 1-3 heures Accessibilité débutants 84/100
Baseflow/flutter-geocoding#311 · 2 commentaires ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
Baseflow/flutter-geocoding#309 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 38/100
Baseflow/flutter-geocoding#287 · 1 commentaire ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
Baseflow/flutter-geocoding#286 · 2 commentaires ·
Toutes les issues de Baseflow/flutter-geocoding
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
bannzai/medicalarm#478 ·
Les mainteneurs répondent en général sous 1 jour
-
genkit_anthropic: responses with an empty or unknown usage.service_tier fail with FormatException: Unknown ServiceTierPeut-être pris @kenzieschmoll l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
genkit-ai/genkit-dart#686 ·
Les mainteneurs répondent en général sous 3 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
aaronified/fluenough#918 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
VeryGoodOpenSource/very_good_analysis#255 ·
Les mainteneurs répondent en général sous 1 jour