Recherche avancée

Sur d’autres sites (7257)

• Anomalie #3697 : Bug svn10000 SPIP 3

  14 février 2016, par MiKaël Navarro

  Cependant je m’étonne que cette erreur là « remplissent les logs du serveur Web », d’autant que l’erreur n’est pas critique.
  Normalement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false. Par contre, oui ça créait une erreur PHP si le dossier n’existait pas, mais qui ne devrait pas perturber il me semble la suite du processus de mise à jour. Je n’ai pas été vérifier cependant.

  Effectivement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false, mais ce n’est pas le code que j’ai dans l’archive spip-3.1.zip (r22707 aujourd’hui en date du 6 janvier), au lieu de ça j’ai seulement (sans le if) :
  

  $dir = opendir($base) ;
  while (($f = readdir($dir)) !== false) 
  ...
  

  De plus je suis d’accord, ce n’est pas une Erreur mais un simple Warning que l’on retrouve dans /var/log/nginx/error.log :
  

  2016/02/14 12:36:04 [error] 1141#0 : *197 FastCGI sent in stderr : "PHP message : PHP Warning :  opendir(baddir/) : failed to open dir : No such file or directory in /home/mickey/public_html/test-opendir.php on line 2
  PHP message : PHP Warning :  readdir() expects parameter 1 to be resource, boolean given in /home/mickey/public_html/test-opendir.php on line 3" while reading response header from upstream, client : 127.0.0.1, server : localhost, request : "GET / mickey/test-opendir.php HTTP/1.1", upstream : "fastcgi ://unix :/var/run/php5-fpm.sock :", host : "localhost" 
  

  
  Ensuite le test while (($f = readdir($dir)) !== false) rentre dans une boucle infinie et c’est avec ça que j’ai créé un log de plus de 2Go !

  D’après les commit, je vois que c’était déjà corrigé dans la version SVN, mais un test supplémentaire mange pas de pain ça sera plus robuste et évitera l’écriture d’un Warning dans les logs pour rien :)

  En tout cas merci pour votre réactivité.

• Anomalie #3100 (Nouveau) : Bug - Base PostgreSQL

  20 novembre 2013, par _ CasP

  Bonjour,
  Je viens de créer un site mutualisé sur mon site. Mon ancien site à une base MYSQL et n’a pas de souci.
  En revanche le nouveau site à lui une base PostgreSQL.

  L’hébergement est chez OVH.

  je constate 2 chose étrange la première : lors de l’instalation du site après avoir renseigné le serveur et l’utilisateur, je me retrouve à avoir le choix parmi une multitude de base de donnée. Là ou habituellement je n’ai que le nom de celle que j’ai crée.
  Mais peux être ceci est un souci lié à OVH, je leur ai écrit pour demander.

  Le deuxième Bug a lieu lors de la création de RUBRIQUES dans l’espace privée.
  Cela fonctionne, cependant après la création je me retrouve avec une

  3 Erreur(s) dans le squeletteNuméro Message squelette boucle Ligne
  1 Array / /
  2 Array / /
  3 Array / /

  Warning : pg_query() [function.pg-query] : Query failed : ERREUR : la référence à la colonne « id_rubrique » est ambigu LINE 4 : GROUP BY id_rubrique,lang ^ in /homez.64/casp/www/ecrire/req/pg.php on line 168

  Warning : pg_query() [function.pg-query] : Query failed : ERREUR : la référence à la colonne « lang » est ambigu LINE 4 : GROUP BY id_article,lang ^ in /homez.64/casp/www/ecrire/req/pg.php on line 168

  Warning : pg_query() [function.pg-query] : Query failed : ERREUR : la référence à la colonne « lang » est ambigu LINE 4 : GROUP BY id_breve,lang ^ in /homez.64/casp/www/ecrire/req/pg.php on line 168

  Et je reste sur la page de crétion sans être redirigé. J’ai alors l’option :
  Votre modification a été enregistrée
  Si votre navigateur n’est pas redirigé, cliquez ici pour continuer.
  Tout fonctionne ce n’est donc pas dramatique. Mais c’est un peu gènant.

• x86/tx_float : remove vgatherdpd usage

  20 mai 2022, par Lynne

  x86/tx_float : remove vgatherdpd usage
  Its performance loss ranges from either being just as fast as individual loads
  
  (Skylake), a few percent slower (Alderlake), 8% slower (Zen 3), to completely
  
  disasterous (older/other CPUs).
  Sadly, gathers never panned out fast on x86, even with the benefit of time and
  
  implementation experience.
  This also saves a register, as there's no need to fill out an additional
  
  register mask.
  Zen 3 (16384-point transform) :
  
  Before : 1561050 decicycles in           av_tx (fft),  131072 runs,      0 skips
  
  After :  1449621 decicycles in           av_tx (fft),  131072 runs,      0 skips
  Alderlake :
  
  2% slower on big transforms (65536), to 1% (131072), to a few percent for smaller
  
  sizes.
  

  • [DH] libavutil/x86/tx_float.asm
  • [DH] libavutil/x86/tx_float_init.c