Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ghost-Raider Newsgroups: fr.comp.applications.bureautique Subject: Re: Fuite de memoire dans Open Office et Libre Office : une solution ? Date: Mon, 9 Oct 2023 13:31:02 +0200 Organization: A noiseless patient Spider Lines: 121 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 9 Oct 2023 11:31:02 -0000 (UTC) Injection-Info: dont-email.me; posting-host="c6104739c60f8ea077c08a8781c45195"; logging-data="3906550"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Peox6FB1zIj+UQuJyyYdEthk0G/zhKbI=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:CYXyz2iwq1/FqZYHiX0xFqxB3Q0= In-Reply-To: Content-Language: fr Bytes: 6490 Le 07/10/2023 à 22:06, Denis Beauregard a écrit : > Le Thu, 5 Oct 2023 19:10:43 +0200, Ghost-Raider > écrivait dans > fr.comp.applications.bureautique: > >> Bonjour, >> >> J’utilise Open Office sous Windows 10 ou Libre Office sous Linux Mint >> pour ma compta personnelle qui recouvre une quarantaine d'années. > [...] > >> Les trois fichiers sont légers : moins de 1 MO chaque ce qui s'explique >> par le fait que la plupart des cases sont vides. >> >> J'en viens à mes problèmes. >> >> Bug n° 1 >> On sait que Open Office est un fork de Open Office qui lui-même est un >> héritage de Star Office. > > plutôt Libre Office ici, mais peu importe Erreur de ma part : On sait que *Libre Office* est un fork de Open Office qui lui-même est un héritage de Star Office. > >> Star Office présentait un bug gênant même sur des petits fichiers : de >> temps en temps, ils se plantait sans raison apparente. Pour y pallier, >> il enregistrait en flux continu toutes les opérations. En cas de >> plantage, il proposait à sa réouverture de recharger le fichier dans son >> dernier état. Ce contournement fonctionnait bien et il a été repris dans >> Open Office puis dans Libre Office, mais la cause n'en a jamais été >> corrigée. > > Je travaille avec des gros fichiers XLS (pas la version OD parce que > j'ai commencé avec cela il y a 20 ans) dont plusieurs sont en haut de > 20 Mo. J'ai utilisé LO 3 longtemps parce que LO 4 à 6 ne pouvaient > pas lire ces fichiers trop gros sans planter assez rapidement. Quand > j'ai changé d'ordi pour Win 10, je suis passé à LO 7. Je ne sais pas > si c'est en ajoutant beaucoup de mémoire ou en passant de Win 7 à > Win 10, mais c'est assez stable. Ceci dit, je n'ai jamais vu cette > fonction et j'abandonne de toutes façons la récupération. > > Avec LO 7.5, il y a un problème de lenteur qui est apparu et je viens > de redescendre à LO 7.4.6.2 (que j'avais sur mon disque). Par exemple, > un simple "copier" ou ctrl-C est devenu très lent à répondre. > > >> Bug n°2. >> Open Office et Libre office partagent un autre bug beaucoup plus gênant. >> L'occupation mémoire augmente progressivement à chaque opération car la >> mémoire utilisée n'est jamais libérée. Elle augmente progressivement >> pour atteindre et dépasser 1,2 GO ou plus et là, le programme se plante. >> On le voit en examinant le fichier soffice.bin . > > Mon soffice.bin fait seulement 789 ko et il est daté de mars. Un > autre fichier ? soffice.bin existe sous Windows/Open Office et Windows Libre Office et sous Linux/Libre Office. Mon fichiercalc de test, 154 feuilles de 100 colonnes et 60 lignes, mais 1000 KO seulement. - sous windows/open office/calc il démarre à 150 KO et passe à 800 KO à l'enregistrement. SI je fais des manips, il grimpe encore et se plante à l'enregistrement vers 1300 KO. - sous windows/libre office/calc, il démarre à 800/900 ko mais n'augmente pas beaucoup suite à des manips ni à l'enregistrement. - sous linux/libre office, je ne sais pas bien lire l'occupation mémoire et ses variations, top... j'y reviendrai. > >> Au départ, il occupe déjà volontiers 200 à 400 MO, ce qui est très >> étonnant, puis, il augmente lentement mais sûrement. Si on déplace dans >> un tableau un certain nombre de cellules, par exemple pour insérer des >> lignes ou des colonnes, soffice.bin augmente brusquement et atteint >> facilement 800 ou 900 MO. C'est à l'enregistrement que ça se gâte car >> alors soffice.bin dépasse 1, 2 ou 1,3 GO et le programme se plante, sans >> doute en raison de la limite de 1,6 GO des applications 32 bits. >> Contournement : fermer et rouvrir Open Office ou Libre Office pour faire >> redescendre soffice.bin. C'est la solution des forums usenet (sans rire). > > Au fait, je ne vois pas de fichier qui gonfle. Oui, c'est bizarre. La plupart des gars se plaignent de soffice.bin qui se gonfle sous LO/word alors que moi, c'est OO/calc qui se gonfle et explose comme la grenouille de la fable. J'ai un un fichier OO/word de 13 MO, 600 pages, plein de photos, de tableaux, de notes de bas de page etc. il ne se plante jamais sou OO ou LO et pourtant, il a fait l'objet de centaines de corrections. > >> Bug n°3 >> Uniquement Libre Office : de temps, Libre Office se ferme tout >> simplement et le fichier de sauvegarde au fil de l'eau n'est pas proposé >> à la réouverture, tout le travail récent est perdu. > > J'ai fini par prendre l'habitude de sauvegarder souvent ! > > Depuis une version récente, LO plante parfois quand je copie une > chaîne (pas très longue) dans la boîte de recherche. Alors je suis > devenu un peu parano ! > > >> Le bug n°2 est référencé sur usenet mais aucune solution n'a jamais été >> apportée. >> https://bz.apache.org/ooo/show_bug.cgi?id=94528 >> >> Tous ces bugs sont observables sous Windows ou sous Linux. >> >> Quelqu'un a-t-il une solution ? > > Sauvegarder souvent ? Ben oui. je coince un aperçu du gestionnaire des tâches dans un coin de mon écran et je surveille soffice.bin comme le lait sur le feu. Tout ça est gênant, on ne peut pas faire confiance à des logiciels pourtant entretenu par des armées de développeurs.