Considérons une station de travail (diskless, mais à mon avis, ça
n'a rien à voir ici) qui tourne avec un FreeBSD 12
et par exemple okular ou xpdf.
Si je me connecte sous l'utilisateur A (session X/Windowmaker)
et que je lance xpdf, je me prends un segfault dans la figure. truss
ne m'a été d'aucun secours sur ce coup-là.
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte
par A, je peux lancer xpdf sans aucun problème.
Si je lance maintenant ssh -Y -l A localhost (donc connexion de A
sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne
s'affiche en dehors des décorations de fenêtre (truss montre que
xpdf n'est pas mort et traite bien des appels système).
À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur
le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf
sans problème.
Et là, je sèche. Au début, je pensais qu'il y avait un problème dans
le serveur X local, mais un ssh sur localhost utilise les mêmes
bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux
yeux dans les environnements de A et B.
Est-ce que ça évoque quelque chose à quelqu'un ?
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros de version d'un peu tout, en particulier des clients ssh, serveur sshd, et appli xpdf concernees, ca pourrait peut-etre aider un peu. Faudra sans doute que t'ailles fouiller dans la config du client et du serveur... les distrib vont rarement laisser ce genre de truc tourner tout seul a l'identique.
In article <slrnqf4seb.ifq.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte
par A, je peux lancer xpdf sans aucun problème.
À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur
le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf
sans problème.
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros
de version d'un peu tout, en particulier des clients ssh, serveur sshd, et
appli xpdf concernees, ca pourrait peut-etre aider un peu.
Faudra sans doute que t'ailles fouiller dans la config du client et du
serveur... les distrib vont rarement laisser ce genre de truc tourner tout
seul a l'identique.
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros de version d'un peu tout, en particulier des clients ssh, serveur sshd, et appli xpdf concernees, ca pourrait peut-etre aider un peu. Faudra sans doute que t'ailles fouiller dans la config du client et du serveur... les distrib vont rarement laisser ce genre de truc tourner tout seul a l'identique.
JKB
Le Sat, 1 Jun 2019 18:26:02 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte par A, je peux lancer xpdf sans aucun problème. Si je lance maintenant ssh -Y -l A localhost (donc connexion de A sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne s'affiche en dehors des décorations de fenêtre (truss montre que xpdf n'est pas mort et traite bien des appels système). À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf sans problème. Et là, je sèche. Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux yeux dans les environnements de A et B. Est-ce que ça évoque quelque chose à quelqu'un ?
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros de version d'un peu tout, en particulier des clients ssh, serveur sshd, et appli xpdf concernees, ca pourrait peut-etre aider un peu.
Je ne vois pas trop ce que vient faire ssh là-dedans puisqu'il n'est là que pour prouver que ce n'est pas l'exécutable qui segfaulte sauf lorsqu'il est lancé dans une session graphique sur le poste en question. Je rappelle que mon problème de base, c'est xpdf, okular et quelques autres programmes qui se baugent sur un segfault lorsqu'ils sont lancés directement dans un terminal d'une session graphique. :/usr/ports/textproc/py-recommonmark # uname -a FreeBSD pythagore 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC amd64 :/usr/ports/textproc/py-recommonmark # pkg info xpdf xpdf-4.01_1,1 Name : xpdf Version : 4.01_1,1 ... Installed on : Thu Mar 21 11:48:58 2019 CET Origin : graphics/xpdf Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : print graphics Licenses : GPLv2 Maintainer : WWW : http://www.xpdfreader.com/ Comment : Display PDF files and convert them to other formats Options : GUI : on LIBPAPER : off PRINT : on TYPE1 : on Shared Libs required: libQt5Network.so.5 libpng16.so.16 libQt5PrintSupport.so.5 libcups.so.2 libQt5Core.so.5 libpaper.so.1 libfreetype.so.6 libQt5Gui.so.5 libQt5Widgets.so.5 Annotations : FreeBSD_version: 1200086 Flat size : 14.1MiB Description : Xpdf is a viewer for Portable Document Format (PDF) files. These are also sometimes also called 'Acrobat' files, from the name of Adobe's PDF software. It can also convert PDF input to ps, text, and info formats; and split out fonts and images. WWW: http://www.xpdfreader.com/ :/usr/ports/textproc/py-recommonmark # ssh -V OpenSSH_7.8p1, OpenSSL 1.1.1a-freebsd 20 Nov 2018 Le client ssh côté Linux est OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1b. Côté NetBSD, il s'agit d'un OpenSSH_7.6 NetBSD_Secure_Shell-20171007, OpenSSL 1.0.2k.
Faudra sans doute que t'ailles fouiller dans la config du client et du serveur... les distrib vont rarement laisser ce genre de truc tourner tout seul a l'identique.
Oui mais non. J'ai dû mal m'exprimer. Si l'utilisateur A se connecte directement sur la console graphique, il ne peut lancer certains programmes sans que cela échoue sur un segfault. S'il se connecte au travers de ssh depuis un poste distant sur la machine en question, il peut lancer les programmes sans problème. Je pensais donc à un souci de serveur X. Or si, depuis la session sur la machine fautive, A se reconnecte à la _même_ machine au travers d'un ssh localhost, il _peut_ utiliser les programmes qui segfaultaient dès qu'ils étaient lancés depuis un xterm. Or dans les deux cas, les bibliothèques sont les mêmes (on est sur la _même_ machine). ssh/sshd ajoute certes une couche, mais je ne vois pas par quel miracle il pourrait faire qu'un programme qui échoue sur un segfault, lancé directement dans un terminal, puisse fonctionner en passant par un tunnel sur l'interface réseau loopback. Bien cordialement, JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Sat, 1 Jun 2019 18:26:02 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrnqf4seb.ifq.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte
par A, je peux lancer xpdf sans aucun problème.
Si je lance maintenant ssh -Y -l A localhost (donc connexion de A
sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne
s'affiche en dehors des décorations de fenêtre (truss montre que
xpdf n'est pas mort et traite bien des appels système).
À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur
le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf
sans problème.
Et là, je sèche. Au début, je pensais qu'il y avait un problème dans
le serveur X local, mais un ssh sur localhost utilise les mêmes
bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux
yeux dans les environnements de A et B.
Est-ce que ça évoque quelque chose à quelqu'un ?
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros
de version d'un peu tout, en particulier des clients ssh, serveur sshd, et
appli xpdf concernees, ca pourrait peut-etre aider un peu.
Je ne vois pas trop ce que vient faire ssh là-dedans puisqu'il n'est
là que pour prouver que ce n'est pas l'exécutable qui segfaulte sauf
lorsqu'il est lancé dans une session graphique sur le poste en
question.
Je rappelle que mon problème de base, c'est xpdf, okular et quelques
autres programmes qui se baugent sur un segfault lorsqu'ils sont
lancés directement dans un terminal d'une session graphique.
root@pythagore:/usr/ports/textproc/py-recommonmark # uname -a
FreeBSD pythagore 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC amd64
root@pythagore:/usr/ports/textproc/py-recommonmark # pkg info xpdf
xpdf-4.01_1,1
Name : xpdf
Version : 4.01_1,1
...
Installed on : Thu Mar 21 11:48:58 2019 CET
Origin : graphics/xpdf
Architecture : FreeBSD:12:amd64
Prefix : /usr/local
Categories : print graphics
Licenses : GPLv2
Maintainer : cy@FreeBSD.org
WWW : http://www.xpdfreader.com/
Comment : Display PDF files and convert them to other formats
Options :
GUI : on
LIBPAPER : off
PRINT : on
TYPE1 : on
Shared Libs required:
libQt5Network.so.5
libpng16.so.16
libQt5PrintSupport.so.5
libcups.so.2
libQt5Core.so.5
libpaper.so.1
libfreetype.so.6
libQt5Gui.so.5
libQt5Widgets.so.5
Annotations :
FreeBSD_version: 1200086
Flat size : 14.1MiB
Description :
Xpdf is a viewer for Portable Document Format (PDF) files. These are
also sometimes also called 'Acrobat' files, from the name of Adobe's
PDF software.
It can also convert PDF input to ps, text, and info formats; and
split out fonts and images.
Le client ssh côté Linux est OpenSSH_7.9p1 Debian-10, OpenSSL
1.1.1b. Côté NetBSD, il s'agit d'un OpenSSH_7.6
NetBSD_Secure_Shell-20171007, OpenSSL 1.0.2k.
Faudra sans doute que t'ailles fouiller dans la config du client et du
serveur... les distrib vont rarement laisser ce genre de truc tourner tout
seul a l'identique.
Oui mais non. J'ai dû mal m'exprimer.
Si l'utilisateur A se connecte directement sur la console graphique,
il ne peut lancer certains programmes sans que cela échoue sur un
segfault. S'il se connecte au travers de ssh depuis un poste distant
sur la machine en question, il peut lancer les programmes sans
problème. Je pensais donc à un souci de serveur X.
Or si, depuis la session sur la machine fautive, A se reconnecte à
la _même_ machine au travers d'un ssh localhost, il _peut_ utiliser
les programmes qui segfaultaient dès qu'ils étaient lancés depuis un
xterm. Or dans les deux cas, les bibliothèques sont les mêmes (on
est sur la _même_ machine). ssh/sshd ajoute certes une couche, mais
je ne vois pas par quel miracle il pourrait faire qu'un programme
qui échoue sur un segfault, lancé directement dans un terminal,
puisse fonctionner en passant par un tunnel sur l'interface réseau
loopback.
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sat, 1 Jun 2019 18:26:02 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte par A, je peux lancer xpdf sans aucun problème. Si je lance maintenant ssh -Y -l A localhost (donc connexion de A sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne s'affiche en dehors des décorations de fenêtre (truss montre que xpdf n'est pas mort et traite bien des appels système). À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf sans problème. Et là, je sèche. Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux yeux dans les environnements de A et B. Est-ce que ça évoque quelque chose à quelqu'un ?
Pas grand chose, mais cote methodologie, deja, si tu donnais les numeros de version d'un peu tout, en particulier des clients ssh, serveur sshd, et appli xpdf concernees, ca pourrait peut-etre aider un peu.
Je ne vois pas trop ce que vient faire ssh là-dedans puisqu'il n'est là que pour prouver que ce n'est pas l'exécutable qui segfaulte sauf lorsqu'il est lancé dans une session graphique sur le poste en question. Je rappelle que mon problème de base, c'est xpdf, okular et quelques autres programmes qui se baugent sur un segfault lorsqu'ils sont lancés directement dans un terminal d'une session graphique. :/usr/ports/textproc/py-recommonmark # uname -a FreeBSD pythagore 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC amd64 :/usr/ports/textproc/py-recommonmark # pkg info xpdf xpdf-4.01_1,1 Name : xpdf Version : 4.01_1,1 ... Installed on : Thu Mar 21 11:48:58 2019 CET Origin : graphics/xpdf Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : print graphics Licenses : GPLv2 Maintainer : WWW : http://www.xpdfreader.com/ Comment : Display PDF files and convert them to other formats Options : GUI : on LIBPAPER : off PRINT : on TYPE1 : on Shared Libs required: libQt5Network.so.5 libpng16.so.16 libQt5PrintSupport.so.5 libcups.so.2 libQt5Core.so.5 libpaper.so.1 libfreetype.so.6 libQt5Gui.so.5 libQt5Widgets.so.5 Annotations : FreeBSD_version: 1200086 Flat size : 14.1MiB Description : Xpdf is a viewer for Portable Document Format (PDF) files. These are also sometimes also called 'Acrobat' files, from the name of Adobe's PDF software. It can also convert PDF input to ps, text, and info formats; and split out fonts and images. WWW: http://www.xpdfreader.com/ :/usr/ports/textproc/py-recommonmark # ssh -V OpenSSH_7.8p1, OpenSSL 1.1.1a-freebsd 20 Nov 2018 Le client ssh côté Linux est OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1b. Côté NetBSD, il s'agit d'un OpenSSH_7.6 NetBSD_Secure_Shell-20171007, OpenSSL 1.0.2k.
Faudra sans doute que t'ailles fouiller dans la config du client et du serveur... les distrib vont rarement laisser ce genre de truc tourner tout seul a l'identique.
Oui mais non. J'ai dû mal m'exprimer. Si l'utilisateur A se connecte directement sur la console graphique, il ne peut lancer certains programmes sans que cela échoue sur un segfault. S'il se connecte au travers de ssh depuis un poste distant sur la machine en question, il peut lancer les programmes sans problème. Je pensais donc à un souci de serveur X. Or si, depuis la session sur la machine fautive, A se reconnecte à la _même_ machine au travers d'un ssh localhost, il _peut_ utiliser les programmes qui segfaultaient dès qu'ils étaient lancés depuis un xterm. Or dans les deux cas, les bibliothèques sont les mêmes (on est sur la _même_ machine). ssh/sshd ajoute certes une couche, mais je ne vois pas par quel miracle il pourrait faire qu'un programme qui échoue sur un segfault, lancé directement dans un terminal, puisse fonctionner en passant par un tunnel sur l'interface réseau loopback. Bien cordialement, JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Philippe Michel
On 2019-06-01, JKB wrote:
Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que vous pensez a priori ?. Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en particulier dans la partie "number of extensions" et la liste qui suit ?
On 2019-06-01, JKB <jkb@koenigsberg.invalid> wrote:
Au début, je pensais qu'il y avait un problème dans
le serveur X local, mais un ssh sur localhost utilise les mêmes
bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais
pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que
vous pensez a priori ?.
Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en
particulier dans la partie "number of extensions" et la liste qui suit ?
Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que vous pensez a priori ?. Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en particulier dans la partie "number of extensions" et la liste qui suit ?
JKB
Le Sun, 2 Jun 2019 08:49:23 -0000 (UTC), Philippe Michel écrivait :
On 2019-06-01, JKB wrote:
Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que vous pensez a priori ?. Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en particulier dans la partie "number of extensions" et la liste qui suit ?
J'ai naturellement vérifié. Les sorties de xdpyinfo sont strictement identiques dans tous les cas... JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Sun, 2 Jun 2019 08:49:23 -0000 (UTC),
Philippe Michel <philippe.michel7@sfr.fr.invalid> écrivait :
On 2019-06-01, JKB <jkb@koenigsberg.invalid> wrote:
Au début, je pensais qu'il y avait un problème dans
le serveur X local, mais un ssh sur localhost utilise les mêmes
bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais
pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que
vous pensez a priori ?.
Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en
particulier dans la partie "number of extensions" et la liste qui suit ?
J'ai naturellement vérifié. Les sorties de xdpyinfo sont strictement
identiques dans tous les cas...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sun, 2 Jun 2019 08:49:23 -0000 (UTC), Philippe Michel écrivait :
On 2019-06-01, JKB wrote:
Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques.
Le serveur X et les clients sont linkés avec les mêmes, évidemment, mais pour l'utilisation c'est moins sûr. Vous avez vérifié ou c'est ce que vous pensez a priori ?. Un xdpyinfo en local et via ssh -Y ne donne pas de différences, en particulier dans la partie "number of extensions" et la liste qui suit ?
J'ai naturellement vérifié. Les sorties de xdpyinfo sont strictement identiques dans tous les cas... JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Andre Majorel
On 2019-06-01, JKB wrote:
Considérons une station de travail (diskless, mais à mon avis, ça n'a rien à voir ici) qui tourne avec un FreeBSD 12 et par exemple okular ou xpdf. Si je me connecte sous l'utilisateur A (session X/Windowmaker) et que je lance xpdf, je me prends un segfault dans la figure. truss ne m'a été d'aucun secours sur ce coup-là. Si je fais un ssh -Y -l B localhost à partir de la session X ouverte par A, je peux lancer xpdf sans aucun problème. Si je lance maintenant ssh -Y -l A localhost (donc connexion de A sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne s'affiche en dehors des décorations de fenêtre (truss montre que xpdf n'est pas mort et traite bien des appels système). À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf sans problème. Et là, je sèche. Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux yeux dans les environnements de A et B. Est-ce que ça évoque quelque chose à quelqu'un ?
Quand le serveur X est local, il est je pense courant que les applis en tirent parti, notamment en utilisant des pixmaps et ximages en mémoire partagée (XShmCreatePixmap(3) au lieu de XCreatePixmap(3) et XShmCreateImage(3) au lieu de XCreateImage(3)). Il est possible que l'insertion d'SSH entre client et serveur empêche le client de traiter le serveur comme local. Puisqu'il doit utiliser des fonctions différentes, il passe par des chemins d'exécution différents, ce qui pourrait expliquer que ça segfaulte dans un cas mais pas dans l'autre. Un appel à XShmAttach(3) qui échoue avec un BadAlloc serait un bon indice que le client a supposé local un serveur qui ne l'était pas. -- André Majorel http://www.teaser.fr/~amajorel/ Si le nationalisme est un vice, le patriotisme peut-il être une vertu ?
On 2019-06-01, JKB <jkb@koenigsberg.invalid> wrote:
Considérons une station de travail (diskless, mais à mon avis, ça
n'a rien à voir ici) qui tourne avec un FreeBSD 12
et par exemple okular ou xpdf.
Si je me connecte sous l'utilisateur A (session X/Windowmaker)
et que je lance xpdf, je me prends un segfault dans la figure. truss
ne m'a été d'aucun secours sur ce coup-là.
Si je fais un ssh -Y -l B localhost à partir de la session X ouverte
par A, je peux lancer xpdf sans aucun problème.
Si je lance maintenant ssh -Y -l A localhost (donc connexion de A
sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne
s'affiche en dehors des décorations de fenêtre (truss montre que
xpdf n'est pas mort et traite bien des appels système).
À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur
le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf
sans problème.
Et là, je sèche. Au début, je pensais qu'il y avait un problème dans
le serveur X local, mais un ssh sur localhost utilise les mêmes
bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux
yeux dans les environnements de A et B.
Est-ce que ça évoque quelque chose à quelqu'un ?
Quand le serveur X est local, il est je pense courant que les
applis en tirent parti, notamment en utilisant des pixmaps et
ximages en mémoire partagée (XShmCreatePixmap(3) au lieu de
XCreatePixmap(3) et XShmCreateImage(3) au lieu de
XCreateImage(3)).
Il est possible que l'insertion d'SSH entre client et serveur
empêche le client de traiter le serveur comme local. Puisqu'il
doit utiliser des fonctions différentes, il passe par des
chemins d'exécution différents, ce qui pourrait expliquer que ça
segfaulte dans un cas mais pas dans l'autre.
Un appel à XShmAttach(3) qui échoue avec un BadAlloc serait un
bon indice que le client a supposé local un serveur qui ne
l'était pas.
--
André Majorel http://www.teaser.fr/~amajorel/
Si le nationalisme est un vice, le patriotisme peut-il être une vertu ?
Considérons une station de travail (diskless, mais à mon avis, ça n'a rien à voir ici) qui tourne avec un FreeBSD 12 et par exemple okular ou xpdf. Si je me connecte sous l'utilisateur A (session X/Windowmaker) et que je lance xpdf, je me prends un segfault dans la figure. truss ne m'a été d'aucun secours sur ce coup-là. Si je fais un ssh -Y -l B localhost à partir de la session X ouverte par A, je peux lancer xpdf sans aucun problème. Si je lance maintenant ssh -Y -l A localhost (donc connexion de A sur A sur la même machine), xpdf ne segfaulte plus, mais rien ne s'affiche en dehors des décorations de fenêtre (truss montre que xpdf n'est pas mort et traite bien des appels système). À partir d'un NetBSD ou d'un Linux, je peux me connecter en ssh sur le FreeBSD en question quel que soit l'utilisateur pour lancer xpdf sans problème. Et là, je sèche. Au début, je pensais qu'il y avait un problème dans le serveur X local, mais un ssh sur localhost utilise les mêmes bibliothèques. J'avoue ne plus rien comprendre, rien ne me saute aux yeux dans les environnements de A et B. Est-ce que ça évoque quelque chose à quelqu'un ?
Quand le serveur X est local, il est je pense courant que les applis en tirent parti, notamment en utilisant des pixmaps et ximages en mémoire partagée (XShmCreatePixmap(3) au lieu de XCreatePixmap(3) et XShmCreateImage(3) au lieu de XCreateImage(3)). Il est possible que l'insertion d'SSH entre client et serveur empêche le client de traiter le serveur comme local. Puisqu'il doit utiliser des fonctions différentes, il passe par des chemins d'exécution différents, ce qui pourrait expliquer que ça segfaulte dans un cas mais pas dans l'autre. Un appel à XShmAttach(3) qui échoue avec un BadAlloc serait un bon indice que le client a supposé local un serveur qui ne l'était pas. -- André Majorel http://www.teaser.fr/~amajorel/ Si le nationalisme est un vice, le patriotisme peut-il être une vertu ?
