Crash CGImageRef vm_copy failed

Réponses

• klog Membre

  mai 2019 #2

  Ca ressemble à un problème d'alignement mémoire (doc vm_copy concernant source_address et dest_address)
• [Utilisateur supprimé]

  mai 2019 #3

  C'est aussi ce que j'avais trouvé mais les solutions proposé n'ont rien résolu.

  En mettant WebPFreeDecBuffer(&config.output); après CGImageRef cgImage = ... au lieu d'avant a réglé le problème.

  Résolu.

  Merci
• [Utilisateur supprimé]

  mai 2019 mai 2019 modifié #4

  Mouaip, en faisant ça ça me bouffe toute ma RAM... avec un seul dossier lu contenant des fichiers WebP au lieu de rester à 25Mo d'occupation je passe à 650Mo.

  Si je passe en revue tout mes répertoire je passe à plus de 20Go de ram occupé

  penser à rajouter un CGImageRelease(cgImage);
• Joanna Carter Membre, Modérateur

  mai 2019 #5

  Peut-être, j'ai trouvé pourquoi ça bouffe la memoire. Dans FolderView.m, tu as une boucle qui appelle [[Comic alloc] initWithFullPath:path]. Ce qui appelle, à son tour, decodeWebP, où se trouve le crash.

  Avec ce type de boucle, tu devrais penser d'utiliser NSAutoReleasePool

      for (NSString *str in array)
      {
        @autoreleasepool
        {
          NSString *path = [NSString stringWithFormat:@"%@/%@", SidebarView.getPath, str];
  
          Comic *comic = [[Comic alloc] initWithFullPath:path];
  
          [comArray addObject:comic];
        }
      }
  
• [Utilisateur supprimé]

  mai 2019 #6

  @Joanna Carter a dit :
  Peut-être, j'ai trouvé pourquoi ça bouffe la memoire. Dans FolderView.m, tu as une boucle qui appelle [[Comic alloc] initWithFullPath:path]. Ce qui appelle, à son tour, decodeWebP, où se trouve le crash.

  Avec ce type de boucle, tu devrais penser d'utiliser NSAutoReleasePool

      for (NSString *str in array)
      {
        @autoreleasepool
        {
          NSString *path = [NSString stringWithFormat:@"%@/%@", SidebarView.getPath, str];
          
          Comic *comic = [[Comic alloc] initWithFullPath:path];
          
          [comArray addObject:comic];
        }
      }
  

  En fait c'était le CGImage qui bouffait la RAM, le CGImageRelease à résolu le problème. Ca me maintient l'occupation de la RAM à 25-35Mo max.

  Par contre j'en suis à me demander si @autoreleasepool a encore son utilité, partout ou je l'ai testé ça n'a absolument rien changé.
• Céroce Membre, Modérateur

  mai 2019 #7

  @Harlo a dit :
  En fait c'était le CGImage qui bouffait la RAM, le CGImageRelease à résolu le problème. Ca me maintient l'occupation de la RAM à 25-35Mo max.

  Par contre j'en suis à me demander si @autoreleasepool a encore son utilité, partout ou je l'ai testé ça n'a absolument rien changé.

  On a au moins un autorelease pool à tout moment dans une appli.
  En créer un autre se justifie quand on crée un grand nombre d'objet (disons >10 000) qui ont une durée de vie courte. Typiquement, ça sert pour effectuer un traitement lourd, puis relâcher la mémoire juste après.
  On parle bien d'allocation d'objets (NSObject), donc effectivement, ça n'aura aucune incidence sur la gestion mémoire de CoreGraphics.
• Pyroh Membre

  mai 2019 #8

  Sauf exception, tout ce qui commence en CF ou CG et qui finit par Ref n'est pas managé par l'ARC. Tu dois donc faire le release toi-même. Comme les pointeurs en C.
• [Utilisateur supprimé]

  mai 2019 #9

  Merci pour les infos, c'est bon à savoir.
• [Utilisateur supprimé]

  mai 2019 mai 2019 modifié #10

  On trouve des choses intéressante en fouinant dans les SDK.

  Pour ma Queue qui s'occupe du décodage de mes imgs -> DISPATCH_QUEUE_CONCURRENT_WITH_AUTORELEASE_POOL
• [Utilisateur supprimé]

  mai 2019 mai 2019 modifié #11

  error
• OldNick Membre

  mai 2019 #12

  @Pyroh a dit :
  Sauf exception, tout ce qui commence en CF ou CG et qui finit par Ref n'est pas managé par l'ARC. Tu dois donc faire le release toi-même. Comme les pointeurs en C.

  Bon à savoir - merci Pyroh !