Re: Fuite de mémoire dans Open Office et Libre Office : une solution ?

Le 11/10/2023 à 08:19, Thierry HOUX a écrit :

Le Tue, 10 Oct 2023 19:42:31 +0200, Ghost-Raider a écrit :
 

Le 10/10/2023 à 05:55, Thierry HOUX a écrit :

Le Mon, 9 Oct 2023 20:50:45 +0200, Ghost-Raider a écrit :
>

Le 09/10/2023 à 19:13, christian a écrit :

Le Mon, 9 Oct 2023 18:31:27 +0200, Ghost-Raider a écrit :
>

Sauf erreurs, Open Office et Libre Office sont en 32 bits.

>
Comment l'as-tu déterminé?

>
De mémoire, mais je me suis trompé. J'ai répondu à Nicolas George :
chez moi : OO en 32 bits, LO en 64 bits, avec toujours la même fuite.

>
Chez moi (Debian 12),Libre-office est en 64 bits (sauf erreur de ma
part)

>
Pas d'erreur de ta part.

>

Mon PC Linux fait 16 GO de RAM et c'est pareil, soffice.bin devient
énorme dès l'ouverture de LO.

>
chez moi, il ne bouge pas d'un octet (14672 octets) quoi qu'il arrive
>
Est-ce qu'on parle du même fichiers?

>
Il n'y a qu'une instance de soffice.bin à ma connaissance, qui
apparaît dès que je lance le logiciel et qui disparaît dès que je le
ferme, constatations faite sous Windows et sous Linux.
Et c'est bien ce fichier qui enfle jusqu'à dépasser 1 GO et qui finit
par se planter.
>

J'imagine que c'est toute la structure initiale de l'information qui
est foireuse et qu'il faudrait tout casser pour résoudre ce problème
qui ne semble pas vraiment remuer les foules et qui est, finalement,
facile à contourner.

>
ben, s'il faut tout casser, c'est pas si simple :-)
>

Non, c'est certainement trop compliqué puisque cette fuite de mémoire
date de Star Office dont  ma version, la 5.2, a plus de 20 ans d'âge
et n'a jamais été corrigée.
On peut consulter sur le web des tas de messages sur ce problème,
jamais résolu.

>
Peut-être pas un problème dû à soffice.bin mais qui a des conséquences
sur ce dernier. Se méfier de la conséquence visible et de la cause qui
peut- être ailleurs, en l'occurrence calc peut-être?

>
calc et  writer ont la même maladie mais ça dépend des gens  et du
moment.
>
Essais :
1 - j'ouvre sous OO mon  fichier test qui ne pèse que 1012 kO.
soffice.bin est créé et pèse 167300 kO !
165 fois plus lourd !
je crée un fichier de vidage (DMP), il pèse 393116 kO.
J'ouvre ce fichier de vidage : il est "corrompu", plantage.
>
2 - J'ouvre mon fichier test sous LO soffice.bin est créé : 590920 kO
584 fois plus lourd !
Je crée un fichier de vidage (DMP), il pèse 1249293 kO J'ouvre ce
fichier de vidage : il est "corrompu", plantage.
>
Pourquoi les fichiers soffice.bin sont-ils si gros ?
Pourquoi sont-ils bien plus gros sous LO que sous OO ?
Pourquoi les fichiers DMP sont-ils "corrompus" ?
>
Voilà, voilà...

 Si je comprends bien comment ça fonctionne, soffice.bin est disons le
noyau de LO / OO. C'est lui qui est chargé, en fonction de ton choix de
travailler avec writer ou calc, de charger les modules correponsdants et
les libraires de dépendances.

OK.

La différence entre OO et LO est certainement due aux évolutions qui ont
eu lieu entre les deux suites.

Oui. LO a été "amélioré" par rapport à OO.
Chez moi, je constate qu'il est moins fiable que OO, ce qui est reconnu sur les sites où on les compare.

Les fait que tu aient le même problème sur les deux provient d'une partie
historique commune aux deux suites. Si ce problème est identifié depuis
longtemps et pas encore traité est certainement du au fait de la
priorisation faite pour traiter les "bugs"; ce dernier devant être réputé
de fréquence "rare" sa priorité est basse.

C'est certainement vrai et ça me laisse peu d'espoir de correction.
Je connais d'autres bugs de LO ou OO, parfois communs, parfois non.
Ils n'ont pas été corrigés depuis des lustres mais ils sont d’occurrences très rares.

 DMP: Le plantage doit avoir lieu au moment ou il est écrit?

Si j'essaye de le lire par un éditeur de texte, on me dit qu'il est corrompu.

 Bon, difficile d'aller plus loin, ça deviendrait de l'art devinatoire hors
de mon champ de compétences.
 

Et surtout du mien.
--
Courrier envoyé par mon top super extra PC Hardware.fr sous Linux Mint
Cinnamon