c’est pas interdit de mettre Jessie + Stretch
apt sait gérer la version la plus récente de chaque paquet et ça te permets de conserver openjdk-7 puisqu’il n’est que dans Jessie
jessie + stretch
suivi de
sudo apt update
sudo apt full-upgrade
Le reste c’est tes salades avec ta version d’image, ceci ne me regarde pas 
Pour info j’ai lancé libreoffice --strace pour produire le fichier strace.log que vous pouvez consulter. Je vois en particulier de nombreux fichiers manquants, en particulier à la ligne 722 du fichier strace.log :
3148 13:14:48.431806 open("/usr/lib/libreoffice/program/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Je ne comprends pas pourquoi libreoffice viendrait avec son propre fichier libc.so.6 … A moins que ce soit parce que ce serait la version Jessie … Je pense qu’il y a autre chose que cette histoire de Bug Java Stretch 32 bits…
Bref. OK pour le full upgrade … Mais je comprends que je dois garder uniquement les paquets stretch de base et demander le full ugrade… Non ?
j’essaie simplement de te dire que mettre les paquets officiels de stretch + openjdk-7 de jessie dont tu dis avoir besoin est un environnement plus propre que d’utiliser des dépôts exotiques.
et tester ta rustine sur le noyau 32 bits , stack_guard_gap=1, dans cet environnement
Oui, tout a fait d’accord 
J’ai fait un upgrade, mais uniquement avec les paquets Stretch. Et cela ne marche toujours pas même avec la lancement du noyau avec le paramètre stack_guard_gap=1.
Je viens de réactiver les dépôts Jessie et je réinstalle OpenJDK-7. Apt m’indique de très nombreux paquets (la plupart des paquets pythons, certains backports, etc. ) à virer … ce qu’il est en train de faire…
Sans succès 
J’ai pourtant bien installé OpenJDK-7, j’utilise la ligne de commande ci-dessous pour lanceer mon noyau, avec le bon paramètre :
BOOT_IMAGE=/vmlinuz-4.18.0-0.bpo.1-686-pae root=/dev/mapper/gelinux-root ro stack_guard_gap=1 apparmor=1 security=apparmor
Et j’utilise libreoffice du dépôt stretch de base, donc version 1:5.2.7-1+deb9u4. J’ai fait un full upgrade avec mon sources.list comme ci-dessous :
# Debian Stretch, dépôt principal
deb http://deb.debian.org/debian/ stretch main
# Debian Stretch, mises à jour de sécurité
deb http://security.debian.org/ stretch/updates main
# Debian Stretch, mises à jour "volatiles"
deb http://deb.debian.org/debian/ stretch-updates main
deb http://deb.debian.org/debian-security/ jessie/updates contrib main non-free
deb http://deb.debian.org/debian/ jessie main
Alors là, je ne vois pas pourquoi ça ne marche toujours pas … Mon application Base semble planter au moment de l’ouverture de la première boite de dialogue, dans la librairie… J’ai mis en commentaire tout mon code et lorsque j’execute un simple MsgBox “Hello Wolrd” ça plante avec en console le warning ci-dessous :
(soffice:4403): GLib-GObject-WARNING **: /build/glib2.0-YYXhFA/glib2.0-2.50.3/./gobject/gsignal.c:3492: signal name 'selection_changed' is invalid for instance '0x282fe08' of type 'OOoAtkObjCompTxt'
J’ai l’impression que le problème viendrait d’ailleurs. Peut-être à cause d’une librairie, en particulier Access2BAse qui n’est peut être la même version que celle utilisée par mon application, et qui rendrait mon installation instable… En tout cas, si je n’execute aucun script basic libreoffice se charge sans problème. Mais le moindre script executé et tout s’écroule. Et je sais maintenant par expérience, que lorsque il y a une erreur de syntaxe ou un problème de librairie j’ai les même symptômes : les points d’arrêt ne fonctionnent pas, et l’application entière crash … Ce n’est pas un bug dnas mon code, mais bien un problème d’installation, un composant incompatible … un problème de version de quelque chose …
1ere remarque
pourquoi ne mets tu pas contrib et non-free de stretch?
ou bien pourquoi les mets tu pour Jessie?
2ieme remarque
tu es dans un environnement particulier que tu ne décris pas
quand je veux passer des paramètres au noyau je le fais dans /etc/default/grub
Exemple
GRUB_CMDLINE_LINUX_DEFAULT=“loglevel=2 splash apparmor=1 security=apparmor radeon.pcie_gen2=0 btusb.enable_autosuspend=n”
je ne sais pas ce qu’est sysgard
Les dépots Jessie sont ceux qui m’ont été communiqué ci-dessus dans ce trhead …
J’installe bien mon paramètre dans le fichier /etc/default/grub de la façon suivante :
GRUB_CMDLINE_LINUX_DEFAULT="stack_guard_gap=1"
J’ai aussi un fichier apparmor spécific dans /etc/default/grub.d :
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"
Je viens de faire un test. J’ai créé une nouvelle base qui utilise donc hsqldb en interne. Je peux afficher une boite de dialogue sans aucun crash … Le problème viendrait donc maintenant de l’intérieur de mon fichier base et de mes macros. J’ai désactivé tout lancement de macro au démarrage de mon application. Puis j’ai testé une simple fonction pour lancer une macro et cela provoque le crash de libreoffice. Il y aurait donc quelque chose de charger (ou non chargé) avec mon document base qui provoquerait une instabilité au point de cracher ma première macro “hello wolrd” …je continu ma recherche …
certes mais ça n’empêche pas d’être cohérent ou bien tu ne te sers jamais de contrib et non-free?
https://wiki.debian.org/fr/SourcesList#Composants
Si je comprends bien , finalement c’est ton code perso qui est toxique
Non, pas tout à fait, mon code fonctionnait très bien avant l’update de ma debian et donc de LibreOffice.
Simplement mon code utilise la librairie Access2Base livrée en version 1.5 avec LibreOffice 5.2.7.2 et peut être aussi avant avec la version 5.2.7.1. Mais l’année dernière je crois me souvenir que j’avais upgradé manuellement dans libreoffice cette librairie avec sa version la plus récente … Et donc l’update de Debian aurait cassé cette installation manuelle et en réinstallant une version différente de celle utilisée par mon appli… LibreOffice basic étant très instable, cela pourrait expliquer le crash de tout le système.
J’essaye donc d’upgrader à nouveau Access2Base de sa version 1.5 vers la dernière version 1.9 pour vérifier cette hypothèse …
???
c’est intégré à libreoffice
http://www.access2base.com/access2base.html
apt policy libreoffice
libreoffice:
Installé : 1:6.1.3~rc1-2
Candidat : 1:6.1.3~rc1-2
Table de version :
1:6.2.0~alpha1-1 1
1 http://deb.debian.org/debian experimental/main amd64 Packages
*** 1:6.1.3~rc1-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
1:5.2.7-1+deb9u4 500
500 http://deb.debian.org/debian-security stretch/updates/main amd64 Packages
500 http://deb.debian.org/debian stretch/main amd64 Packages
1:4.3.3-2+deb8u11 500
500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
500 http://deb.debian.org/debian jessie/main amd64 Packages
Oiu, c’est à intégré à libreoffice. Mais c’est un problème de version, si je veux access2Base 1.9 sur LibreOffice 5.2.7 je dois l’installer moi même …
Je reviens vers une autre hypothèse, car je viens de découvrir que mon fichier Base est en fait infecté par un virus … Je comprends que ce serait le module PUA.Doc.Tool.LibreOfficeMacro-2 dans mon fichier Base. Je ne sais pas s’il est un module de base de libreoffice, il ne semble pas un des miens … Il n’est peut être pas vraiment utile à mon application, dans un premier temps je vais peut être essayer de travailler sur une copie de ma base pour le virer …
Cela est en lien avec mon autre post sur la consommation de mon CPU par une attaque sha256sum… Je comprends que ce virus provoquerait aussi le crash de mon application au lancement de la première macro.
J’ai découvert le fichier infecté avec Clamav, installé après l’infection… Voir bilan ci-dessous. Je ne connais pas bien Clamav, aussi je ne vois pas comment s’il est possible de réparer le fichier… J’ai simplement mis mon fichier en quarantaine. Je ne sais pas non plus comment utiliser Clamav pour connaître quel type de virus infecte mon fichier. Que fait pour récupérer mon application Base? Heureusement que ma base de donnée est dans un serveur hsqldb séparé …
ClamTk, v5.24
Mon Nov 5 18:07:56 2018
Signatures ClamAV : 6708433
Dossiers analysés :
/home/gelinp/04_PROGRAMMATION/projets/TypodocOoo
1 virus potentiel(s) trouvé(s) menace (1 fichier analysés).
/home/gelinp/04_PROGRAMMATION/projets/TypodocOoo/TypodocOOoHSQLDBclient.odb PUA.Doc.Tool.LibreOfficeMacro-2
-------------------------------------------------------------------------------------------------------------------------comme indiqué dans le tableau que j’ai affiché au-dessus c’est intégré dans libreoffice 1.6.1 disponible dans Debian Buster ( testing)
Bonjour,
Je viens de trouver la vrai raison du crash de ma version LibreOffice : une simple Sub CmdSelectionner() qui rentrait en conflit avec une constante CmsSelectionner = 1005 !!! Cela suffit pour provoquer un crash au démarrage de Libreoffice avec impossibilité de poser un seul point d’arrêt nul part dans aucune librairie …
Ce bug a coincidé exactement avec l’actualisation de mon système et donc l’attribuait à tord la source du crash à l’actualisation de mon noyau et au fameux bug 32 bit avec Java … Je ferme donc l’incident et bascule sur le forum OpenOffice pour discuter des problèmes de convention de nomage spécifiques aux macros OOo Basic … Je vais aussi réessayer d’installer la version 6 de LibreOffice.
La piste du virus dans le fichier n’était finalement pas bonne non plus puisque Clamav semble produire de nombreux faux positifs, et j’ai observé aujourd’hui, avec un autre antivirus moderne et bien actualisé , qu’il ne trouvait aucun virus … Et aucun secteur défectueux sur mon disque dur non plus.
En tout cas merci pour votre aide. Les messages postés serviront quand même à d’autres qui h=chercheront peut être les raisons d’un crash similaire.