Libreoffice 5.2.7.2 de Stretch crash avec base et hsqldb

Support Debian
#1

Bonjour,

J’ai reinstallé mon portable avec debian stretch et libreoffice 5.2.7.2
qui vient par défaut dans les paquets de la distribution. Depuis j’essaie
d’utiliser le module base mais j’ai de nombreux crash au moment de
l’utilisation des tables ou même de la création de la base. Cela avec le driver
hsqldb 2.4.0 (dernière version téléchargée a part, mais aussi avec la version 1.8 fournie avec libreoffice 5.2.7.2), en mode embeded ou client/serveur.

J’ai essayé plusieurs combinaisons des composants : hsqldb 2.3.4 / 1.8.0
et java openjdk 1.8.0_141 / Oracle jdk 1.8.0_144, mais rien n’y fait, le
module est totalement inutilisable, il crash dès que libreoffice accède
aux tables et même systématiquement lorsque je test la classe du driver
hsqldb org.hsqldb.jdbc.JDBCDriver…

J’ai tout de même une connexion qui fonctionne avec le driver postgresql
natif, je crois que c’est un driver sdbc, mais celui-ci a des restrictions
d’usage pour les fonctions de libreoffice, par exemple il n’est pas possible
d’utiliser l’assistant de création de tables, et d’autres restrictions
encore embêtantes pour le développement… Au final cela n’est pas très
encourageant de me lancer dans un développement …

Serait–il seulement possible de lancer libreoffice en mode debug pour voir les
traces ?
Le forum libreoffice me conseille d’installer une version plus stable de libreoffice, la version 5.2.4.1…

Je vous remercie pour votre aide.
Patrick

#2

Bonjour,

Que donne en retour la commande suivante ?

$ dpkg --print-architecture

#3

dpkg --print-architecture
i386

Notez que je viens d’installer dbeaver, celui-ci installe un driver hsqldb de maeven, et il vient de se connecter sans aucun problème a mon serveur HSQLDB. Le driver de maeven et celui de mon serveur ont la même version 2.4.0…

J’ai aussi desinstaller la version libreofice 5.2.7.2 pour la remplacer par une version plus stable, la 5.2.4.1 mais cela ne change rien…

Je m’aperçois de plusieurs choses concernant l’URL JDBC qui sur mon tutoriel est indiquée pour une connexion client (et adaptée sur ma base typodoc) de la façon suivante : jdbc :hsqldb:hsql://localhost/typodoc avec une classe org.hsqldb.jdbc.JDBCDriver.

Je viens de réaliser un test de connexion utilisant le driver fournit par libreoffice 5.4.2.1 : /opt/libreoffice5.4/program/classes/hsqldb.jar

Dbeaver indique effectivementun message d’erreur : java.sql.SQLException: Connection is broken: java.io.EOFException Que signifie cette erreur ?

La même connection, avec des paramètres identiques, mais utilisant le driver maeven proposé par dbeaver fonctionne très bien …

#4

En 32bits (i386), il y a depuis le lancement de stretch des problèmes connus avec libreoffice.

Bug#869161: libreoffice-base crashes with code 139 when creating a new base or opening an existing one

Une partie de ces problèmes a été corrigée mais apparemment il en reste.

Combien de RAM y a-t-il ?

#5

Quantité de RAM (en Go)
gelinp@gelinux:~/04_PROGRAMATION/projets/libreoffice541/hsqldblibreoffice/org/hsqldb/jdbc$ free -g
** total used free shared buff/cache available
Mem: 1 1 0 0 0 0
Swap: 3 0 3

Je ne comprends pas, je suis persuadé d’avoir un portable avec plus de 1Go de mémoire RAM… Avec le swap je comprends donc que cela ferait 4 Go disponible …

Avec le programme hardinfoi j’ai effectivement 2 Go de RAM :
-Memory-
Total Memory : 2059140 kB
**Free Memory : 167072 kB
MemAvailable : 256520 kB
Buffers : 49516 kB
Cached : 377920 kB
Cached Swap : 50344 kB
Active : 1293408 kB
Inactive : 507940 kB
Active(anon) : 1128788 kB
Inactive(anon) : 391500 kB
Active(file) : 164620 kB
Inactive(file) : 116440 kB
Unevictable : 96 kB
Mlocked : 96 kB
High Memory : 1176404 kB
Free High Memory : 37800 kB
Low Memory : 882736 kB
Free Low Memory : 129272 kB
Virtual Memory : 4173820 kB
Free Virtual Memory : 3567392 kB
Dirty : 36 kB
Writeback : 0 kB
AnonPages : 1358384 kB
Mapped : 179312 kB
Shmem : 146372 kB
Slab : 51112 kB
SReclaimable : 31956 kB
SUnreclaim : 19156 kB
KernelStack : 4208 kB
PageTables : 15160 kB
NFS_Unstable : 0 kB
Bounce : 0 kB
WritebackTmp : 0 kB
CommitLimit : 5203388 kB
Committed_AS : 4671144 kB
VmallocTotal : 122880 kB
VmallocUsed : 0 kB
VmallocChunk : 0 kB
HardwareCorrupted : 0 kB
AnonHugePages : 0 kB
ShmemHugePages : 0 kB
ShmemPmdMapped : 0 kB
HugePages_Total : 0
HugePages_Free : 0
HugePages_Rsvd : 0
HugePages_Surp : 0
Hugepagesize : 2048 kB
DirectMap4k : 40952 kB
DirectMap2M : 870400 kB

Avec ces deux infos contradictoires je ne sais pas combien j’ai vraiment de mémoire …

J’ai essayé de changer de kernel, même problème avec :

  • 4.12.0-0.bpo.1-686-pae
  • 4.9.0.3.686-pae
#6

free a une façon particulière d’arrondir…

Utiliser plutôt : free -h

#7

free -h
total used free shared buff/cache available
Mem: 2,0G 1,1G 178M 167M 663M 595M
Swap: 4,0G 68M 3,9G

Cela me semble effectivement plus cohérent. Donc 2Go de mémoire vive… Ce n’est pas beaucoup…

#8

2Go de RAM pour un système 32 bits, c’est déjà pas mal.

Je traîne encore avec un 64 bits couplé à 1Go de RAM depuis 10 ans.

Sachant qu’une partie part dans le GPU… bref !

Cette histoire de stack clash, java, linux, gcc, sauce 32 bits me paraît bien obscure.

#9

Je lis encore les posts sur les différents forums au sujet du bug que vous m’avez communiqué ci-dessus. En upgradant mon kernel à la version 4.12.0-0.bpo.1-686-pae j’ai reçu un un message d’erreur différent avec dbeaver et sa connexion jdbc à hsqldb : Cette fois il indique qu’une socket n’arrive à s’ouvrir et la connexion ne peut donc pas s’établir avec le serveur hsqldb.

C’est donc effectivement un problème au niveau du stack TCP/IP, c’est à dire la pile de programmes nécessaire au fonctionnement des appels TCP/IP.

J’ai essayé de me connecter en mode autonome à la hsqldb, c’est à dire avec un accès aux fichiers de la base en dehors du document odb. Je pensais ne pas faire appel au stack TCP/IP mais cela ne semble pas le cas, j’ai un crash similaire aux autres. Je comprends que du moment que j’utilise jdbc il doit y avoir un appel au stack TCP/IP en local avec la boucle 127.0.0.1 …

#10

Un peu plus de précision que le code de retour 139 avec gdb.

$ gdb /usr/lib/libreoffice/program/soffice.bin
...
...
...
(gdb) run
...
...
...

Dès qu’on clique sur Tables

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0xaafbdf95 in _expand_stack_to(unsigned char*) () from /usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
(gdb)

Dès que la jvm veut se faire un peu de place, boom !

EDIT

Comme il est écrit dans le rapport de bug, ça fait suite aux mises à jour de sécurité pour combler la faille Stack Clash : tout ce qui touche java dans libreoffice sur i386 devient inutilisable.

Anything using Java in LO will crash on i386 after the Stack Clash
security fixes which happened after the stretch release.

#869161 - libreoffice-base crashes with code 139 when creating a new base or opening an existing one - Debian Bug report logs

Il n’y a pas de bonne solution pour résoudre le problème pour le moment.

Sauf à changer de matériel et oublier définitivement le 32 bits i386…

MAUVAIS CONTOURNEMENT EFFICACE

Attention : ceci annule la protection contre les attaques exploitant Stack Clash

Avantage : libreoffice-base fonctionne normalement en 32 bits

Passer stack_guard_gap=1 en paramètre au boot.

Ceci ne peut être qu’une solution de secours temporaire.

#11

Merci beaucoup pour l’info. Effectivement cela semble bien être le problème que je cherchais à résoudre. Il date d’une mise à jour de sécurité publiée en juin 2017. C’est donc une régression …

Je n’ai pas encore trouvé la syntaxe à respecter sur la ligne de commande grub pour passer l’option stack_guard_gap=1 …

J’ai trouvé dans le lien ci-dessous l’info suivante :
https://lists.debian.org/debian-security-announce/2017/msg00160.html
"For the stable distribution (stretch), this problem has been fixed in
version 4.9.30-2+deb9u2."

Je comprends qu’il y aurait donc un kernel corrigé pour stretch … Mais je ne le vois pas dans synaptique et la commande uname -r sur mon noyau montre une version encore plus récent et cela ne corrige rien … :

gelinp@gelinux:~$ uname -r
4.12.0-0.bpo.1-686-pae

Alors est ce bien d’un noyau qu’il s’agit dans la version version 4.9.30-2+deb9u2 en question ?

#12

Oui mais il ne s’agit pas du même problème : celui cité concernait tout autant les systèmes 64 bits que les 32.

Le problème posé aux systèmes 32 bits et uniquement eux est encore non résolu et concerne tous les noyaux et tous les java (openjdk 9 dans sid).

EDIT

Le problème semble toujours se manifester avec les dernières versions du noyau du 20 septembre 2017 (DSA 3981-1).

#13

Je confirme qu’en 32 bits LibreOffice base crashes, alors que sur un autre disque (même machine) il ne semble pas avoir de problème en 64 bits.
Mais je ne suis pas assez “confident” avec Linux Debian pour aller plus loin.
le Gardian

#14

Ce n’est pas spécifique à debian.

Chercher libreoffice stack clash exec shield avec un moteur de recherche donne des bonnes lectures (en anglais).

#15

Inutile d’envoyer un nouveau rapport de bug, ce bug est connu et toujours présent avec debian 9.2.0 i386 (mise à jour intermédiaire de stretch).

#16

La version 4.14.2-1 du noyau linux dans sid ajoute une exception pour éviter les accidents java.

* [x86] mmap: Add an exception to the stack gap for Hotspot JVM compatibility
  (Closes: #865303)

EDIT

Les versions 4.9.65-1 dans stretch et 3.16.51-1 dans jessie contiennent aussi le correctif.

Pour buster, un barrage est apparu :

We think 4.14.2-1 should not yet enter testing

#883558 - linux: not yet ready to enter testing - Debian Bug report logs