Jump to content
mahiiro

[SOLVED] Erreur de time out à la création d'une catégorie

Recommended Posts

Bonjour, 

 

Je travaille sur un site prestashop, 1.6.0.14 en multiboutique et j'ai essayé d'ajouter une nouvelle catégorie, et c'est impossible, voici ce qui s'affiche : 

 

Ce site est inaccessible

La connexion a été réinitialisée.

ERR_CONNECTION_RESET

 

Dans mes logs je retrouve : Mon Apr 04 12:16:31 2016] [error] [client 109.212.198.171] [host leluhome.com] Script timed out before returning headers: index.php 

 

J'ai activé le mode debug et j'ai Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65484 bytes) in /home/lelushop/www/classes/Category.php on line 431 

 

Ce qui est étrange car je peux sans problème créer ou modifier un produit sans dépasser les limites de mémoires. 

 

Dans ce fichier category.php à la ligne 431 j'ai : 

if (isset($categories[(int)$id_category]['subcategories'])) {

            foreach ($categories[(int)$id_category]['subcategories'] as $id_subcategory) {
                Category::_subTree($categories, (int)$id_subcategory, $n);
            }
        }
 
Est ce que quelqu'un à une idée de ce qui m'arrive ?

 

 

Merci !

 

Edited by mahiiro (see edit history)

Share this post


Link to post
Share on other sites

Combien de catégories avez-vous?

 

How many categories do you have?

Share this post


Link to post
Share on other sites

Il est fort probable que la méthode _subTree s'appelle elle-même en boucle indéfiniment. On peut imaginer qu'elle trouve l'identifiant de la catégorie à enregistrer parmi les identifiants des sous-catégories de cette même catégorie.

 

Le mieux serait de placer des var_dump pour vérifier les valeurs, d'aller voir aussi dans la base de données ce qu'il en est, d'utiliser Xdebug, voire de ré-installer le tout avec la dernière version de Prestashop, histoire de partir sur une base saine. Il y a des modules spécifiques installés ? Des modifications particulières apportées aux comportements de Prestashop ?

Share this post


Link to post
Share on other sites

Malheureusement , si il y a une boucle dans l'arbre des catégories (ce n'est donc plus un arbre mais un graphe général), l'exporter et le ré-importer dans une autre installation PS n'y changera rien, si?

 

Il va falloir aller explorer la BDD et trouver la boucle. Pourriez-vous exporter et publier la table ps_category?

Share this post


Link to post
Share on other sites

Bonjour, 

 

Voici la table en question.

 

Le site en question vines d'être passé en multiboutique et connecté à un ERP.

 

J'ai ajouté ca au fichier category : 

if (isset($categories[(int)$id_category]['subcategories'])) {
            foreach ($categories[(int)$id_category]['subcategories'] as $id_subcategory) {
                Category::_subTree($categories, (int)$id_subcategory, $n);
                var_dump($id_subcategory);
            }
        }
 
Puis ca : 
var_dump($categories[(int)$id_category]['subcategories']); die();
        if (isset($categories[(int)$id_category]['subcategories'])) {
            foreach ($categories[(int)$id_category]['subcategories'] as $id_subcategory) {
                Category::_subTree($categories, (int)$id_subcategory, $n);
                var_dump($id_subcategory);
            }
        }
 
Mais je n'ai que ce message : 
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 36 bytes) in /home/lelushop/www/classes/Category.php on line 430
 
Qui s'affiche.
 
Merci ! 

 

ps_category.txt

Share this post


Link to post
Share on other sites

Je vois 3 problèmes dans votre table de catégories. Le premier et le second, c'est que les 5 derniers enregistrements ont un champ id_category égal à 0, dont un représentant une catégorie racine alors qu'il ne devrait y en avoir qu'un seul à priori, et alors que ce champ id_category devrait être unique (auto-incrémenté). Le troisième, et c'est probablement ce qui provoque le dépassement de mémoire allouée à PHP, c'est que les valeurs nleft et nright sont extrêmement élevées et forcément incorrectes. Ce sont des valeurs intervallaires, qui devraient toutes être comprises entre 1 et 144 dans votre cas. 

 

Difficile de dire ce qui a pu se passer. Il y a possibilité de modifier les valeurs à la main dans votre base de données, si ce n'est pas possible de tout reprendre à 0, mais il vous faut comprendre le fonctionnement de chaque champ, en regardant également les autres tables ps_category_ .

Edited by GuillaumeCW (see edit history)

Share this post


Link to post
Share on other sites

Effectivement, les 5 derniers enregistrements sont incorrects (id_category = 0) et du coup vous avez des boucles (0,1,0 et 0,1,2,0).

Effacez-les de la BDD et recommencez la création d'une nouvelle catégorie.

 

Si ça persiste, faites appel à un spécialiste. Vous avez joué avec du multi-boutique? Perso, je n'ai toujours pas compris comment gérer les catégories dans un environnement multi-boutique...

Share this post


Link to post
Share on other sites

Dans votre premier post, vous indiquez utiliser la version 1.6.0.14 de Prestashop. Les lignes 430/431 que vous indiquez ne correspondent pas avec le code visible dans cette version. Mais comme l'indique erouvier29, $categories[(int)$id_category]['subcategories'] doit probablement être un énorme tableau que PHP n'arrive pas à afficher du fait des mauvais id_category des 5 derniers enregistrements.

 

La création d'une catégorie, après avoir activé le multi-boutiques, et avec un contexte "Toutes les boutiques" actif, fonctionne correctement de mon côté. Je testerai à l'occasion de créer une catégorie avec un contexte de boutique spécifique actif... ce que vous semblez avoir fait puisque parmi les 5 derniers enregistrements de catégories, certains ont 1 comme valeur id_shop_default, d'autres 3. Pour mon site en multi-boutiques, toutes les catégories ont l'identifiant 1, qui est celui de la boutique par défaut. Les catégories sont ainsi partagées avec les autres boutiques. C'est là qu'il y a un flou "artistique" de Prestashop, effectivement.  :)

Share this post


Link to post
Share on other sites

Oui en effet mes derniers essais d'ajouts de catégorie on créé des catégories avec un ID = 0. 

J'ai déjà essayé d'effacer toutes les catégories avec un ID = 0 mais ca n'a rien donné. 

 

Et oui pardon je suis en version 1.6.1.2 je me suis trompée. 

Share this post


Link to post
Share on other sites

J'ai supprimé toutes les catégories avec un id = 0 et j'ai modifier tous les nleft et nright pour qu'ils soient compris entre 0 et 144. Et je message persiste

Share this post


Link to post
Share on other sites

En mettant un var_dump( $categories_array ) à la ligne 420, vous obtenez quoi ? Ça devrait être un tableau de ce style :

  • 0 => [ 'subcategories' => [ 0 => 1 ] ]
  • 1 => [ 'subcategories' => [ 0 => 2 ] ]
  • 2 => [ 'subcategories' => [ 0 => 6, 1 => 7, 2 => 8, 3 => 9,... 22 => 86 ] ]
  • ...
  • 14 => [ 'subcategories' => [ 0 => 15 ]

Si l'erreur survient encore, c'est que la "fuite" de mémoire intervient avant cette fonction. En utilisant vos données de catégories, je mesure un peu plus de 1 M bytes de consommation. Votre configuration vous permet d'en utiliser 128 M au maximum. Cette consommation peut être mesurée avec memory_get_usage(). Vous pouvez placer un enregistrement de la consommation au début du traitement de la requête (dans index.php donc), et remonter petit à petit depuis la méthode subTree avec un second enregistrement ( (valeur fin - valeur début) * 8), pour trouver le problème.

 

A noter qu'il y a toujours 2 catégories racines parmi vos catégories (id_category 2, ce qui est normal, et id_category 6).

 

Quel est votre logiciel ERP, par curiosité ? Vous l'avez connecté avant ou après avoir identifié ce problème ?

Edited by GuillaumeCW (see edit history)

Share this post


Link to post
Share on other sites

Bonjour, 

 

 

J'ai constaté l'erreur après la connexion de l'ERP. Le logiciel est EBP.  C'est une société externe qui a fait la connexion mais ils m'ont affirmé que ca venait pas d'eux. Même si je ne crois pas trop aux coïncidences, ils ont pas l'air de s'intéresser à ce problème donc j'essaie de trouver une solution moi même. 

 

Quand j'ai mis un var_dump à la ligne 420, je me retrouve toujours avec l'erreur. Mais je ne sais pas comment faire pour remonter de index à  la méthode subTree.

Share this post


Link to post
Share on other sites

_subTree est appelée par regenerateEntireNtree, qui est appelée par add, qui est appelée par processAdd dans /classes/controller/AdminController.php, etc... Pas besoin de mesurer la consommation en fait, car si l'exécution de PHP arrive à être interrompue (par un die), c'est que la fuite de mémoire intervenait après l'interruption.

 

Notez qu'avec Xdebug, l'identification du problème serait plus rapide, car le temps d'exécution serait indiqué pour chaque fonction appelée. Probablement que régler _PS_MODE_DEV à true dans config/defines.inc.php permettrait aussi d'avoir ces informations.

Share this post


Link to post
Share on other sites

Re

 

J'ai activé les modes de debug, j'ai bien plein d'informations quand je charge une page mais quand j'ai l'erreur 

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /home/lelushop/www/tools/profiling/Db.php on line 107
Il n'y a que ca qui s'affiche. 
 
J'ai essayé pleins de choses, importer mes catégories d'une version antérieure.
D'ailleurs l'erreur à changé de fichier : 
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /home/lelushop/www/tools/profiling/Db.php on line 107
 
Je ne sais plus quoi faire, je suis allée dans le fichier /classes/controller/AdminController.php et je n'ai pas trouvé "regenerateEntireNtree, qui est appelée par add, qui est appelée par processAdd".
 
Au point ou j'en suis je veux même bien payer qq'un pour qu'il déboguer ca, avis aux intéressés. 
 
Merci 

Share this post


Link to post
Share on other sites

Petit up, maintenant que j'essaie de voir une catégorie sur mon site, j'ai une erreur 404 alors que je peux accéder aux produits sans aucun problèmes.

Share this post


Link to post
Share on other sites

Bonjour,

 

juste pour savoir.

 

Vous avez un hébergement mutualisé, vps ou dédié et chez qui ?

Combien de produits et de catégories ainsi que de client ?

 

PrestaShop demande de plus en plus de ressources et en multi boutique, à moins d'être au minimum sur un VPS c'est chercher les ennuis.

 

De plus, avez vous essayé d'augmenter la mémoire alloué à PHP ?

 

Elle est à combien actuellement ?

Share this post


Link to post
Share on other sites

Bonjour, 

 

Ah oui en effet ca pourrait être ca alors. SI c'est ca c'est plutôt une bonne nouvelle !

Share this post


Link to post
Share on other sites

128MB pour indexer 70 catégories, ce devrait être suffisant. J'ai importé votre table ps_category dans une installation 1.6.1.2 après avoir supprimé les 5 derniers enregistrements, et créé une nouvelle catégorie sans problème. La réindexation s'est bien faite.

 

Si vous avez fait la même chose, et que vous avez toujours le problème (un nouvel enregistrement avec id_category = 0), c'est certainement que le schéma de votre BDD a été modifié, sans doute lors de l'initialisation de la connexion avec votre ERP. Ce que vous nous avez transmis n'est absolument pas normal car violant la contrainte de clé primaire (5 enregistrements avec id_category = 0). Vérifiez votre schéma (id_category doit être en clé primaire + auto incrément), et insistez auprès de qui a mis en place la connexion.

Share this post


Link to post
Share on other sites

Je suis trop c.., on l'avait sous les yeux depuis le début (votre export de la table ps_category):

CREATE TABLE IF NOT EXISTS `ps_category` (
  `id_category` int(10) unsigned NOT NULL,
  `id_parent` int(10) unsigned NOT NULL,
  `id_shop_default` int(10) unsigned NOT NULL DEFAULT '1',
  `level_depth` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `nleft` int(10) unsigned NOT NULL DEFAULT '0',
  `nright` int(10) unsigned NOT NULL DEFAULT '0',
  `active` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `date_add` datetime NOT NULL,
  `date_upd` datetime NOT NULL,
  `position` int(10) unsigned NOT NULL DEFAULT '0',
  `is_root_category` tinyint(1) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Les contraintes de clé primaire et d'auto-incrément ont effectivement sauté, sans doute à la mise en place de la connexion EBP.

 

Deux possibilités:

  • Soit c'est un oubli après la manip, demandez alors au prestataire de les rétablir.
  • Soit c'est volontaire, et il ne vous a pas tout dit, ou vous n'avez pas tout retenu. Il me semble que beaucoup de connecteurs de ce genre ne fonctionnent pas en mode bi-directionnel par simplification. Ils fonctionnent typiquement en flux montant pour les produits/stocks/catégories et en flux descendant pour les commandes. Dans ce cas, vous ne pouvez pas créer de produit/catégorie directement depuis le BO PrestaShop, mais vous devez obligatoirement le faire depuis l'ERP

Share this post


Link to post
Share on other sites

Augmenter la mémoire allouée ne résoudra effectivement pas votre problème, je pense. Votre export de table de catégories nous a montré plusieurs problèmes, probablement avec une seule et même origine. Le lien effectué par erouvier entre le schéma corrompu de cette table, et une connexion à ERP qui l'aurait modifié, est le plus pertinent. Ne pas mettre l'id_category en auto-incrémentation permettrait au ERP de les gérer lui-même. Cela expliquerait aussi les valeurs nleft, nright, et is_root_category, qui ne sont pas "normales" pour un Prestashop standard.

 

Mais bref, cela sort complètement du contexte d'un rapport de bug de Prestashop, et le mieux serait effectivement de vous rapprocher du prestataire pour corriger le problème d'une part, et surtout bien comprendre le fonctionnement de la passerelle.

Share this post


Link to post
Share on other sites

Bonjour, 

 

Merci pour toutes cette aide ! Le prestataire ne m'est d'aucun secours malheureusement, montrant de la mauvaise volonté pour nous aider à corriger les problèmes et même à mettre en place la connexion (actuellement tous les produits de mon site n'ont plus les bon prix...).

 

Merci encore je vais voir du coté des clés primaires.  

Share this post


Link to post
Share on other sites

Le problème est que si vous rétablissez la clé primaire + l'auto incrément, le connecteur avec EBP risque de ne plus fonctionner...

Share this post


Link to post
Share on other sites

Bonjour, 

 

Je les ai contacté et ils m'ont dit qu'il n'avaient pas fait ca et qu'ils utilisaient exclusivement la connexion API.

 

Au fait j'ai essayé et ca marche encore merci !! 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More