"Bugs" connus et limitations de LXR
Japan Computer Emergency Response Team (JPCERT) a rendu compte en mars 2018 de la découverte d'une vulnérabilité pendant l'été 2017 par Touma Hatano (波多野冬馬 氏). Cette vulnérabilité permet l'exécution de commandes arbitraires avec une chaîne soigneusement élaborée soumise via le formulaire General Search.
Cette vulnérabilité affecte toutes les versions de LXR avec fonction de recherche en plein texte activée depuis la version 1.0.0.
Il est vivement recommandé aux utilisateurs proposant des serveurs LXR visibles depuis l'internet d'effectuer la mise à jour pour se protéger contre cette vulnérabilité.
Les interpréteurs Perl récents deviennent de plus en plus stricts vis-à-vis de la validité des séquences UTF-8 multi-octets. LXR a parfois besoin d'examiner le contenu d'un fichier avant de décider s'il va le traiter ou non. Si ce fichier ne contient pas du texte (c'est une image ou un binaire), il est fort probable que des suites d'octets ne forment pas une séquence UTF-8 valide. Dans ce cas, Perl émet une erreur fatale.
Depuis 2018, nombre de distributions Linux considèrent le module MPM event suffisamment stable pour l'activer par défaut. LXR ne connaissait que prefork et worker. event désorganise l'initialisation d'Apache par LXR, causant une internal error 500 ou, au mieux, l'affichage des scripts LXR en tant que texte.
De plus, event ne semble pas compatible avec mod_perl imposant de revenir à un traitement CGI pur.
Debian semble ne pas établir corectement le répertoire de travail au lancement d'un script CGI. En conséquence, les désignations relatives de fichier qui attendent que le répertoire de travail soit le répertoire racine de LXR seront erronées et une erreur "file not found" sera affichée.
Un fichier de configuration dépend du module Apache mod_version mais Ubuntu Apache (au moins sous Ubuntu 12.04 LTS) ne charge pas le module par défaut. Pour l'activer, exécutez la commande suivante:
et relancez le serveur.
Quand les scripts LXR sont lancés, le répertoire de travail n'est pas positionné sur le répertoire racine de LXR. Les chemins de fichiers en forme relative dans lxr.conf ne peuvent donc pas être résolus correctement.
Pour régler le problème, éditez custom.d/lxr.conf, "HTML subsection" et ajoutez le chemin absolu du répertoire racine de LXR devant toutes les désignations des modèles HTML. Quand c'est fait, copiez le fichier modifé à sa destination finale comme d'habitude.
'stylesheet' et
'alternate_stylesheet'
qui ne sont pas des chemins de fichier mais des références HTML.
À partir de MySQL 5.5.5, le moteur de stockage par défaut devient InnoDB au lieu de MyISAM. Malgré (ou en raison de) une amélioration de la fiabilité des transactions, les performances ont été particulièrement dégradées: le temps d'indexation par genxref est maintenant deux fois plus long.
PostgreSQL offre plusieurs méthodes de connexion à une base de données.
Celle par défaut utilise les sockets Unix.
Dans des circonstances mal élucidées,
la bibliothèque Perl de base de données peut ne pas réussir à accéder
à la base de LXR.
Le palliatif est de demander explicitement la méthode d'accès par TCP
en ajoutant à la fin du paramètre de configuration 'dbname':
host=.
Beaucoup de descriptions de langage sont erronées ou, au mieux, incomplètes. Seuls C, C++ et Perl peuvent être considérés comme fiables.
Ce n'est pas strictement un "bug" de LXR. ctags se sert d'analyseurs rudimentaires pour les langages secondaires (lisez: hormis C et C++). Ces analyseurs n'implémentent pas la grammaire complète du langage.
'range' incorrecte dans lxr.conf
provoque la perte des étiquettes (tags) de version.
La correction de 2.3.3 ne tient pas compte de tous les cas possibles et provoque l'échec de l'indexation dans certaines circonstances.
Bien que les OS acceptent des chemins comportant plusieurs séparateurs d'affilée, LXR n'attend qu'un seul séparateur et un nom de fragment non vide entre les séparateurs.
Une gestion incorrecte de l'indexation hors-ligne (pour permettre un service sans interruption sur les gros arbres) aboutit à une inclusion récursive des bases de données de glimpse dans le répertoire d'indexation, provoquant son embonpoint lors des indexations incrémentales.
Pour vous débarasser des bases de données superflues, lancez genxref avec l'option --reindexall.
En certaines circonstances, le chemin d'un fichier inclus
(dans des instructions comme #include en C ou import et
from en Python) n'était pas correctement adapté pour y ajouter des hyperliens
ce qui aboutissait à une boucle sans fin.
Une confusion malheureuse entre des variables rend le script non compilable.
Les distributions Ubuntu récentes (problème signalé avec 16.10 Server) utilisent le module Apache MPM Event, alors que le fichier LXR de configuration .htaccess ne teste que la présence de Prefork et Worker. Ce choix de module n'est probablement pas spécifique à Ubuntu et peut se retrouver dans d'autres distributions, au moins celles basées sur Debian.
Comme seul Prefork nécessite une initialisation spécifique et qu'il n'y a pas de documentation détillée sur Event, il a été décidé d'initialiser tous les modules MPM de la même façon à l'exception de Prefork.
import
Si votre code Java contient des instructions import static,
l'analyseur échoue sur le mot-clef static
et entre en boucle
ce qui fige l'écran sur la ligne précédente.
Lors d'une tentative de création d'hyperlien sur des éléments <A> ou <IMG>,
l'analyse HTML dérivée du générique peut échouer et ne pas se rattraper,
conduisant à une boucle infinie.
Cet analyseur n'est pas non plus protégé contre les URI "externes"
(comme http://…)
où la double barre oblique est comprise comme un élément vide de chemin.
Deux lignes (419 et 485) dans ident utilisent une syntaxe Perl approximative au lieu d'un code strict. Le commentaire du bug #233 indique un correctif.
À partir de la version 0.11, ce répertoire passe en "lecture seule" pour décourager d'y effectuer des modifications. Il constitue ainsi une référence fiable pour les fichiers hébergés. Toute personnalisation de LXR doit être effectuée dans le répertoire custom.d/ (lxrconf.d/ avant la version 1.0).
La recherche en plein texte n'est pas possible en raison du format particulier de la base de données VCS (comprenez: ce ne sont pas des fichiers ordinaires).
CVS ne gère pas de version de répertoire.
Si vous changez pour une version autre que HEAD,
vous obtenez le message d'erreur redouté "file does not exist".
Environ 0,5 seconde par ligne (sur un processeur à 3.4 GHz!); mais ne jetez pas la pierre à Mercurial, quelque chose ne va pas dans le code LXR interfaçant le système.
Ils n'ont pas la qualité de ceux des compilateurs (ils sont très rudimentaires). Ils se contentent d'extraire de façon lexicale des séquences de caractères qui ressemblent à des identificateurs (sans tenir compte de leur sémantique).
Ignore un éventuel sigil lors de l'assemblage des identificateurs. Cela aboutit à la même décoration de symboles avec des rôles différents.
$
tandis que les fonctions n'ont pas de préfixe.
Ignore la classification des identificateurs puisqu'il ne traite pas la sémantique. Ceci aboutit aussi à une confusion des symboles avec des rôles différents.
Les références URI reçoivent un hyperlien seulement si elles désignent un autre document dans l'arbre-source.
L'analyseur est facilement perturbé si la partie textuelle (en dehors des balises HTML) contient des apostrophes ou des guillemets. Ceci provoque une situation désynchronisée.
En raison d'une limitation de ctags,
seules les sub (et pas une variable) sont indexées.
Les variables sont accidentellement décorées
si leur nom, sans le sigil, est le même que celui d'une fonction.
La présence de caractères tel que #, ' ou
" dans les motifs causeront probablement des situations
désynchronisées.
include ou require recevront des hyperliens
vers le fichier-cible seulement si le nom est une chaîne relative
à la racine de l'arbre-source.
Le nom ne peut pas non plus contenir d'apostrophes (')
ou des guillemets (").
Les inclusions multiples par une seule instruction import
ou from ne sont pas traitées.
Vous pouvez comparez deux fichiers différant seulement par une seule variable.
Vous pouvez comparer deux fichiers différant par autant de variables que vous voulez à conditions de fixer la valeur des variables avant de cliquer sur le bouton "Change".
Les nouvelles différences sont calculées entre la version la plus récemment sélectionnée et la nouvelle, pas entre la version initiale (celle active au moment du clic sur le lien "diff markup") et la nouvelle.