Crash .cxx_destruct

Hello,

J'arrête pas de me taper ce fichu cxx_desctruct qui me parle pas trop

d'après les dires du dev de libzip j'aurais un soucis de "it could be a malloc/free problem in some other code instead"

une piste ?

Réponses

  • klogklog Membre

    Ca ressemble à un problème de communication entre Objective-C et C++ au moment du release de la classe Comic où le destructeur d'une classe C++ pose problème.

    Ton fichier comic.m fait-il appel à des libs C++ ?
    Si c'est le cas (et que ce n'est pas déjà fait) je te conseille vivement de le convertir en fichier Objective-C++ (change l'extension en .mm ou directement dans l'inspecteur du fichier).

    Cela permet d'établir un protocole de communication entre les 2 languages (en définissant par exemple comment les constructeurs ou destructeurs C++ interagissent avec Objective-C++ [appels automatiques]).

  • Aucune lib c++.

    Le point commun à chaque fois que ça crash c'est lors de l'extraction de l'image du .zip pour la mettre en cache.

    Si dans le NSCollectionViewItem j'ai [super prepareForReuse] et [super setRepresentedObject:representedObject] ça m'indiquera que ça crash à l'un de ces 2 endroits.
    Si je les mets en commentaire le crash se reporte ailleurs.

    J'ai désactivé tout les autorelease pour le moment.

    C'est pour le point commun du .zip que j'en ai parlé au dev de libzip mais pour lui le problème serait de mon coté.

    J'ai bien tenté de de supprimer l'async pour voir si y'avait une diff, rien.

    j'ai tenté l'async sur des parties ne l'étant pas pour voir si y'avait besoin d'un p'tit délai de relachement, rien.

    Bien que ce soit un cash constant, il est tout de même relativement aléatoire, c'est en faisant la même chose plusieurs fois de suite que je reproduis. C'est de façon aléatoire que ça se produit, je peux tenter de le mettre en défaut 30 fois, ça crash au bout de 5, de 3 ou de 10 fois.

    Si les images ont déjà été extraite dans le cache, il y a toujours une partie unzip qui perdure, je récupère les infos à afficher dans un fichiers XML lui aussi présent dans l'archive et ça ne pose aucun problème.

    Si je désactive la mise en cache en conservant l'extraction de l'image, crash.

  • klogklog Membre

    Alors c'est peut-être un over-release...

    Actives la détection de Zombie dans Diagnostics / Memory Management / Zombie Object et scrutes les Logs (utilises en complément Zombies dans Instruments si nécessaire).

  • Je ne vois rien qui s'en approche.

  • Réglé le crash mais je sais toujours pas par quoi c'est provoqué, y'a des data perdu en cours de route pour une raison assez obcure.

    J'ai un dispatch_async

    J'extrais mon cover à partir de lui en appelant une méthode

    dans mon dispatch_async le string n'est pas null

    dans la méthode d'extraction le string est null

    si dans mon dispatch_async je met un NSLog pour controler mon string il parvient correctement à la méthode mais pas de log ça disparaît comme par magie

    Les données se perdent alors qu'il n'y a aucune raison valable O_ô

    Y'a des voleurs de string chez la pomme 🤪

    https://github.com/Old-Geek/Librairie/blob/master/Librairie/Cache/ImageCache.m#L48
    https://github.com/Old-Geek/Librairie/blob/master/Librairie/Zip/ExtractCover.m#L38

Connectez-vous ou Inscrivez-vous pour répondre.