1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 583
    Points : 19 830
    Points
    19 830

    Par défaut GNOME Shell affecté par un bogue qui se manifeste par l’augmentation de l'espace RAM occupé toutes les minutes

    GNOME Shell affecté par un bogue qui se manifeste par l’augmentation de l'espace RAM occupé toutes les minutes
    Sur plusieurs distributions Linux

    Des utilisateurs de l’environnement de bureau GNOME Shell rapportent que ce dernier est affecté par un bogue qui a un impact sur son empreinte mémoire. Le comportement erratique de l’application concerne les utilisateurs de plusieurs distributions Linux. Les plaintes ont principalement été formulées au travers de la plateforme launchpad.net d’Ubuntu, mais la vidéo de démonstration du bogue a été réalisée sous la distribution Fedora dérivée de RedHat.

    Nom : gnome-3.26-in-fedora-27.jpg
Affichages : 5623
Taille : 47,1 Ko

    En substance, les utilisateurs d’une version non patchée de GNOME 3.26 sur Ubuntu 17.04, 17.10 et Fedora 27 – pour ne citer que ces distributions – devraient pouvoir reproduire le bogue à l’aide d’actions habituelles comme l’ouverture de l’aperçu, la réduction d’une fenêtre, le basculement entre fenêtres (effectuer la combinaison de touches Alt+tab avec plus de trois fenêtres d’applications ouvertes), etc. La description du bogue disponible sur launchpad.net fait état de ce qu’il y a augmentation de l’empreinte mémoire toutes les minutes ; de plus, l’espace consommé peut aller jusqu’à 2 giga-octets en fonction des animations lancées sur l’environnement de bureau.

    La situation est fâcheuse pour les systèmes munis de peu de mémoire vive ; par contre, au vu de la description, le bogue pourrait passer incognito pour les possesseurs d’ordinateurs bien fournis en RAM.


    Un correctif est disponible pour les utilisateurs de la version 3.26 de l’environnement de bureau. Borislav Anchev – l’auteur de la vidéo de démonstration – rapporte que le bogue est également reproductible sur les builds journalières d’Ubuntu 18.04 livrées avec la version 3.28 de l’environnement de bureau. La première bêta d’Ubuntu 18.04 (Bionic Beaver) est disponible en téléchargement depuis le 13 mars ; la version finale est pour sa part attendue le 26 avril 2018, ce qui signifie que l’on est rendu aux dernières phases du développement. Il semble donc peu probable que le correctif du bogue pour la dernière mouture du système d’exploitation maintenu par Canonical soit disponible dans les temps. GNOME 3.30 est attendu pour le mois d’octobre et devrait intégrer le patch.

    Sur les installations affectées, la seule façon de faire usage de l’environnement de bureau sur de longues durées est de programmer un redémarrage de ce dernier à intervalles de temps réguliers. Un Alt+F2 suivie de la pression sur la touche « r » et d’une validation avec la touche entrée devrait permettre de libérer l’espace mémoire.

    Sources

    Launchpad.net

    Gitlab

    Votre opinion

    Êtes-vous un utilisateur de l’environnement de bureau GNOME Shell ? Si oui, avez-vous fait ce constat ?

    Voir aussi

    GNOME 3.26 est disponible en version stable : « Manchester » s'accompagne d'une amélioration de la recherche et des emojis en couleur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    255
    Détails du profil
    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 255
    Points : 1 010
    Points
    1 010

    Par défaut

    J'ai laissé tomber GNOME (que j'aimais bien) au profit de MATE et CINNAMON depuis l'arrivée du GNOME SHELL que je ne trouve pas
    du tout ergonomique.

    Après, les bugs, ça arrive à tout le monde.... L'important c'est qu'ils réagissent vite et proposent un correctif efficace, mais là, je n'ai
    aucun doute, ce sont de très bons développeurs...

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    juin 2007
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2007
    Messages : 49
    Points : 79
    Points
    79

    Par défaut

    j'ai exactement le même soucis avec Cinnamon, obligé de faite un petit ctrl+alt+esc pour redémarrer l'interface après une journée de taff sinno c'est des micro freeze assurés :<

  4. #4
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    juin 2011
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juin 2011
    Messages : 5
    Points : 7
    Points
    7

    Par défaut GNOME Shell affecté par un bogue qui se manifeste par l’augmentation de l'espace RAM occupé toutes les minutes

    [QUOTE=sergio_is_back;10109590]J'ai laissé tomber GNOME (que j'aimais bien) au profit de MATE et CINNAMON depuis l'arrivée du GNOME SHELL que je ne trouve pas
    du tout ergonomique.

    J'utilise personnellement Gnome shell 3.26 avec Fedora 27, que j'apprécie tout particuliérement niveau ergonomie. (la touche "windows +3 lettres pour lancer n'importe quel programme)
    Bien paramétré, avec ses raccourcis et certaines extensions, c'est une interface trés versatile utilisable, sur PC ou sur les écrans tactiles de tablettes (si Google ou Microsoft, nous le permettent)
    J'utilise également Lxde ou Openbox sur des netbooks ou avec ma clé bootable PuppyLinux.


    J'ai bien constaté ce bug effectivement très génant car certaines fois c'est plus quu'une fois par minute.

  5. #5
    Chroniqueur Actualités

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2013
    Messages : 320
    Points : 8 687
    Points
    8 687
    Billets dans le blog
    1

    Par défaut Les correctifs du bogue « Memory Leak » sur GNOME Shell sont disponibles et seront embarqués dans la 3.28

    Les correctifs du bogue « Memory Leak » sur GNOME Shell sont disponibles et seront embarqués dans la version 3.28
    de l’environnement de bureau

    Les correctifs du bogue « Memory Leak » détecté sur GNOME Shell et qui se manifeste par l'augmentation de l'espace RAM occupé toutes les minutes seront disponibles dans la prochaine version de GNOME. En effet, depuis le jeudi dernier, les deux Merge Request (MR) de Gitlab qui le résolvent ont été fusionnés. Ces changements après des tests concluants ont été reportés sur la version 3.28 de GNOME. Lorsque le bogue a été constaté, plusieurs utilisateurs l’ont signalé via le ticket 1672297 sur launchpad.net. Le souci a été attribué aux animations du GNOME Shell. En effet, des tentatives de reproduction ont montré que GNOME Shell consommait environ 70 MB de mémoire aussitôt après le démarrage. Ce nombre passe à 95 MB après l’ouverture de menu puis à 250 MB après avoir chargé la grille d'icônes.

    Nom : Screen Shot 2018-04-23 at 23.36.34.png
Affichages : 2014
Taille : 76,1 Ko

    Le Garbage Collector est à l’origine du problème. Lorsque des objets en mémoire sont liés par des relations parent/fils, quand on supprime un objet parent il est marqué dans le Garbage Collector. Cette suppression doit normalement entrainer la suppression des objets fils qui lui sont attachés. Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer. Après la suppression, le Garbage Collector n’a aucun moyen de lier les objets. Seuls les objets directement dépendants sont supprimés. Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1. Par conséquent, il ne survient que lorsque plusieurs GObject sont empilés. La fuite de mémoire survient à la suite de cet empilement. Formellement, il ne s’agit pas d’une fuite de mémoire, mais plutôt d’un comportement irrégulier de la mémoire.

    La solution consiste à programmer le Garbage Collector chaque fois qu’un objet est marqué pour suppression. Cette solution bien qu’ayant un léger impact sur la performance reste efficace. En exécutant fréquemment le Garbage Collector, le nombre d’objets à supprimer est réduit. Autrement dit, le léger impact sur la performance est compensé par le gain en mémoire. Au-delà de cette solution préconisée entre autres par l’expert Georges Stavracas, d’autres améliorations ont été apportées. La première modifie la structure de données sous-jacente des objets JS, ce qui permet de passer d’un algorithme dont la complexité est O(n) à un algorithme dont la complexité est réduite à O(1). La seconde amélioration apportée réduit considérablement le nombre d'allocations de mémoire temporaires. Au-delà de ce bogue sur GNOME, un souci de communication au sein de la communauté a été soulevé. Ainsi, Garnacho déplore que certains utilisateurs considèrent GNOME comme le produit de ses développeurs, créant ainsi une barrière entre eux et les nouveaux contributeurs.

    Source : Feaneron

    Et vous ?

    Pensez-vous que la solution préconisée pour résoudre ce problème de mémoire soit la bonne ?

    Voir aussi

    GNOME Shell affecté par un bogue qui se manifeste par l’augmentation de l'espace RAM occupé toutes les minutes sur plusieurs distributions Linux

    GNOME 3.28 est disponible en version stable : « Chongqing » s'accompagne d'un nouveau clavier visuel, et d'une prise en charge plus large des périphériques

    Ubuntu 17.10 Artful Aardvark est disponible, cette version basée sur Linux 4.13 vient avec GNOME et Wayland par défaut

  6. #6
    MikeRowSoft
    Invité(e)

    Par défaut

    Le dernier paragraphe de l'article DVP laisse penser à un choix sans optimisation de l'écriture (implémentation) du code source...
    C'est surtout gênant avec les scripts en général...

    L'impact sur la mémoire RAM était le même en 32 bits et 64 bits ?
    Dernière modification par MikeRowSoft ; 24/04/2018 à 07h05.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    janvier 2014
    Messages
    163
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 163
    Points : 328
    Points
    328

    Par défaut

    ...Quand on supprime un objet parent il est marqué dans le Garbage Collector. Cette suppression doit normalement entrainer la suppression des objets fils qui lui sont attachés. Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer.
    je cite un mémoire sur la "Gestion de cycle de vie des objets" en C++ qui date de 2006 :
    " Certains langages comme C, CH, Ada, Pascal et bien d'autres utilisent une libération explicite de la mémoire. L'avantage majeur de cette libération par rapport au Garbage Collector est sans doute l'emploi des pointeurs, outil très important permettant un accès direct à certaines zones mémoires et une utilisation plus optimale de l'espace mémoire.
    ...
    Puisqu'il est une extension de l'ANSI-C (on lui pardonnera cette simplification réductrice ^^' ), C++ utilise une gestion explicite de la mémoire avec les delete, new, free et malloc. Pour M. A. Ellis et B. Stroustrup (affirmation sur des publications de 1990 à 2000), la gestion de mémoire explicite via le Garbage Collector n'est pas une composante du langage C++.
    Nous proposons dans notre travail de recherche un outil assurant une gestion implicite de la mémoire basé sur la programmation aspect, notamment avec l'extension AspectC++ qui est un préprocesseur pour un compilateur C++ usuel. L'idée est d'implémenter via AspectC++ des compteurs de références pour les objets nouvellement créés. Il s'agit d'attribuer un compteur de références à un objet, d'incrémenter ce compteur chaque fois qu'un autre objet crée une référence vers le premier objet et de décrémenter ce compteur chaque fois qu'une référence est supprimée. L'objet sera détruit dès que son compteur associé sera à zéro. "

    Je lie cette citation à cette partie de l'article :
    Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1. Par conséquent, il ne survient que lorsque plusieurs GObject sont empilés.
    Je pose alors la question ouverte suivante :
    Si le garbage collector n'est toujours pas implémenté en C++, n'y a t'il actuellement aucun équivalent (en terme de fiabilité) au garbage collector en C ou C++ pour ce qui est de la suppression de fils et parents ?
    Participez à la visibilité de l'apport d'un propos, ou l'intérêt que vous en prétez... qu'il soit positif ou négatif : utilisez les pouces d’appréciation.

  8. #8
    Membre éprouvé
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    255
    Détails du profil
    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 255
    Points : 1 010
    Points
    1 010

    Par défaut

    Citation Envoyé par Steinvikel Voir le message
    Je pose alors la question ouverte suivante :
    Si le garbage collector n'est toujours pas implémenté en C++, n'y a t'il actuellement aucun équivalent (en terme de fiabilité) au garbage collector en C ou C++ pour ce qui est de la suppression de fils et parents ?
    A la lecture de l'article, le problème semble se situer sur l’implémentation GJS (JavaScript bindings for GNOME) et pas au niveau C/C++ (à moins que j'ai mal lu)

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    159
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 159
    Points : 395
    Points
    395

    Par défaut

    @Steinvikel : Il existe des garbage collector en C++ pour C++ (par exemple Boehm). D'après ce que je comprends c'est que celui utilsé par Gnome semble un peu particulier.

  10. #10
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    341
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 341
    Points : 1 397
    Points
    1 397

    Par défaut

    Citation Envoyé par Steinvikel Voir le message
    Si le garbage collector n'est toujours pas implémenté en C++, n'y a t'il actuellement aucun équivalent (en terme de fiabilité) au garbage collector en C ou C++ pour ce qui est de la suppression de fils et parents ?
    Le garbage collector est un choix de conception qui a son lot d'inconvénients (latence, non-déterminisme...). Pour la gestion mémoire, C++ propose plutôt le RAII et les smart-pointers (unique_ptr, shared_ptr...).

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    janvier 2014
    Messages
    163
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 163
    Points : 328
    Points
    328

    Par défaut

    Je vais ignorer cette joute plutôt salé, elle me paraît innaproprié.
    Citation Envoyé par codec_abc Voir le message
    @Steinvikel : Il existe des garbage collector en C++ pour C++ (par exemple Boehm). D'après ce que je comprends c'est que celui utilsé par Gnome semble un peu particulier.
    ça me rassure... j'avais lu des choses sur différents mécanismes de suppression il y un certain temps maintenant, et le C avec ce coté manuel qui me rebute n'en n'est pas capable, cela m'étonnait que C++17 ne puisse pas générer un équivalent (s'il n'existe pas encore en natif) au garbage collector... ça serais un comble pour un langage fortement type avec autant de polymorphisme après 20 années de service. ^^'

    Citation Envoyé par SimonDecoline Voir le message
    Le garbage collector est un choix de conception qui a son lot d'inconvénients (latence, non-déterminisme...). Pour la gestion mémoire, C++ propose plutôt le RAII et les smart-pointers (unique_ptr, shared_ptr...).
    Citation Envoyé par sergio_is_back Voir le message
    A la lecture de l'article, le problème semble se situer sur l’implémentation GJS (JavaScript bindings for GNOME) et pas au niveau C/C++ (à moins que j'ai mal lu)
    " Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer. Après la suppression, le Garbage Collector n’a aucun moyen de lier les objets. Seuls les objets directement dépendants sont supprimés. Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1.. "

    C'est pour moi également un peut ambigüe, mais à plusieurs on devrait y voir plus clair. : )
    Je ne connais ni GObject ni GJS, mais je comprends qu'ici, JS et C sont de concert pour un but commun. De ce que j'en tire, c'est que le JS génère des objet et que l'usage du C ne permet pas (ou le code pas conçu pour ??) au garbage collector (en C ou en JS ??) de faire correctement sont boulot. C'est le C qui fout la merde en ne "traçant pas les dépendances des objets".
    A moins que ça implique d'autres tenants et aboutissants que je ne devine pas durant la phase de développement de ce cas de figure (comme communiquer les dépendances de manière détourné ?).
    bref. un peu flou techniquement tout ça pour moi, mais l'aspect général du problème était très intéressant. =)
    Participez à la visibilité de l'apport d'un propos, ou l'intérêt que vous en prétez... qu'il soit positif ou négatif : utilisez les pouces d’appréciation.

Discussions similaires

  1. Réponses: 31
    Dernier message: 25/01/2018, 14h27
  2. Réponses: 0
    Dernier message: 13/10/2017, 09h25
  3. Minuteur qui relance un évenement toutes les minutes
    Par ambi86 dans le forum Général JavaScript
    Réponses: 5
    Dernier message: 27/10/2016, 09h04
  4. [Win XP]Processus Windows qui tourne toutes les minutes
    Par astradream dans le forum Windows
    Réponses: 2
    Dernier message: 17/03/2010, 16h04
  5. Réponses: 1
    Dernier message: 23/01/2007, 18h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo