Erreurs, bugs, questions - page 786

Nouveau commentaire
 

Le fichier .ex5 d'un des indicateurs a augmenté de près de 10 fois sa taille par rapport au fichier .ex5 compilé par la version précédente. Ce n'est pas un problème. Mais une erreur est apparue lors du dessin de l'indicateur (avant la saisie de ses paramètres) :

2012.07.27 02:53:57     MP2012_GRI (EURUSD,M30) Access violation read to 0x000000003FF39D25

J'ai déjà corrigé le code 3\4. Et si je commente encore un peu, je l'obtiendrai (avec l'erreur ci-dessus) :

2012.07.27 02:56:42     Custom Indicator        'MP2012_GRI' may work incorrectly, as it requires more than 256Kb of stack memory
et ça ne marche vraiment pas

Et si je commente à nouveau un peu le code, les deux premières erreurs disparaissent, mais je les obtiens lors du déchargement de l'indicateur:

2012.07.27 02:47:35     MP2012_GRI (EURUSD,M30) 9 leaked strings left
(Les chiffres peuvent être différents - cela dépend de la quantité de code que j'ai commenté)

J'ai découvert à l'avance que ma fonction est trop importante en volume - je la battrai sur de petites fonctions.

... et tout allait bien dans la dernière version.

 
notused:

Le fichier .ex5 d'un des indicateurs a augmenté de près de 10 fois sa taille par rapport au fichier .ex5 compilé par la version précédente. Ce n'est pas un problème. Mais une erreur est apparue lors du dessin de l'indicateur (avant la saisie de ses paramètres) :

J'ai déjà corrigé le code 3\4. Et si je le change un peu plus, j'obtiendrai (avec l'erreur ci-dessus) :

Nous avons renforcé le contrôle de l'environnement sandbox pour une meilleure sécurité.

Le message concernant la pile vous indique que vous avez utilisé plus de 256 kilo-octets de pile dans l'une de vos fonctions, ce qui constitue un problème sérieux en programmation. Par exemple, en C/C++, l'utilisation d'une fonction de pile locale même pour 16Kb est considérée comme un avertissement sérieux.

Vous allouez probablement beaucoup de tableaux statiques dans les fonctions, par exemple :

void func(void)
  {
   double arr1[128000];
   double arr2[128000];
   double arr3[128000];

  }

Vous ne devez pas faire ça.

Si vous avez besoin de tableaux de grande taille, utilisez plutôt des tableaux dynamiques. Par exemple :

double ExtArr[];

void func(void)
  {
   double arr1[];
   double arr2[];

   ArrayResize(ExtArr,128000,0);
   ArrayResize(arr1,128000,0);
   ArrayResize(arr2,128000,0);
  }
Документация по MQL5: Основы языка / Типы данных / Объект динамического массива
Документация по MQL5: Основы языка / Типы данных / Объект динамического массива
  • www.mql5.com
Основы языка / Типы данных / Объект динамического массива - Документация по MQL5
 
Renat:

Nous avons renforcé le contrôle de l'environnement sandbox dans un souci de sécurité accrue.

Le message concernant la pile vous indique que vous avez utilisé plus de 256 kilo-octets dans une fonction de la pile, ce qui est un problème sérieux en programmation. Par exemple, en C/C++, utiliser une pile locale, même de 16 kb, dans une fonction est considéré comme un avertissement sérieux.

Vous allouez probablement beaucoup de tableaux statiques dans les fonctions, par exemple :

Vous ne devriez pas faire ça.

Si vous avez besoin de tableaux de grande taille, utilisez plutôt des tableaux dynamiques. Par exemple :

Je n'utilise pas du tout de tableaux statiques dans cet indicateur ; je ne passe rien de plus lourd que int dans les fonctions, etc. Mais vous utilisez activement toutes sortes de fonctions graphiques.

Par exemple,

   ObjectSetString(0, stmp, OBJPROP_TEXT, "HB");
   ObjectSetInteger(0, stmp, OBJPROP_COLOR, hbColor);

Si la dernière ligne est commentée, tout va bien. Le problème est qu'il y a beaucoup d'appels de ce type et que celui-ci

ObjectSetInteger(0, stmp, OBJPROP_COLOR, hbColor);

est le 20e ou le 30e d'affilée.

Je pense que le problème réside dans la taille de la fonction, puisque commenter le code évite le problème, alors que la majeure partie du code est constituée d'ObjectSetXXX. J'ai découvert, par le biais d'expériences, qu'il est également inutile de le diviser en parties plus petites - un inliner agressif continuera à tout empiler et à générer des erreurs. Je peux essayer de mettre plus de code, mais je le ferai demain. Le bureau de service est aussi demain, si nous ne trouvons pas une solution plus tôt.

 
notused:

Je n'utilise pas du tout de tableaux statiques dans cet indicateur ; je ne passe rien de plus lourd que int dans les fonctions, etc. Mais toutes sortes de fonctions graphiques sont activement utilisées.

Mais il y a quelque chose d'énorme, n'est-ce pas ?

Par exemple, incluez une copie locale d'une classe qui a juste une tonne de tableaux statiques dans ses membres. C'est généralement là que se cachent les dépôts des consommateurs de piles locales.


Par exemple,

Si la dernière ligne est commentée, tout va bien. Le problème, c'est que nous avons beaucoup d'appels de ce type et que celui-ci...

est le 20e ou le 30e d'affilée.

Je pense que le problème réside dans la taille de la fonction, puisque commenter le code permet d'éviter le problème, et que la majeure partie du code consiste en ObjectSetXXX. J'ai découvert, par le biais d'expériences, qu'il est également inutile de le diviser en parties plus petites - un inliner agressif continuera à tout empiler et à générer des erreurs. Je peux essayer de mettre plus de code, mais je le ferai demain. Service Desk également demain, si nous ne trouvons pas de solution avant.

Répartir les fonctions, les empiler en classes.

Inliner n'a probablement rien à voir avec cela - il n'insère pas de trop gros morceaux de code. En particulier s'ils sont lourds et comportent beaucoup de variables locales.

 
Renat:

Mais il y a quelque chose d'énorme, n'est-ce pas ?

Par exemple, incluez une copie locale d'une classe qui a juste une tonne de tableaux statiques dans ses membres. C'est généralement là que se cachent les dépôts des consommateurs de piles locales.


Répartir les fonctions, les empiler en classes.

Inliner n'a probablement rien à voir avec cela - il n'insère pas de trop gros morceaux de code. Surtout s'ils ont beaucoup de variables locales.

Service Desk #444495
 

Pourquoi est-ce que c'est comme ça ? un mauvais paiement ou quoi ! seulement 1 agent a gagné 1 kr et 0.3 kr a fait un paiement par jour !


 

Veillez à écrire à servicedesk avec ces en-têtes :

Version du terminal et débit binaire

...

Description du problème

...

Séquence d'actions ...

...

Résultat obtenu ...

...

Résultat attendu ...

...

Informations complémentaires ...

...

Ou pouvez-vous l'exprimer avec vos propres mots ?

 
Zeleniy:

ou pouvez-vous l'exprimer avec vos propres mots ?

Une liste serait mieux. Cela facilitera grandement la vie de la personne chargée de traiter le bug.
 
Zeleniy:

Devez-vous écrire à Servicedesk avec ces rubriques ?


ou puis-je le faire avec mes propres mots ?

vous pouvez faire tout cela avec vos propres mots, mais

Version du terminal et débit binaire
Description du problème
 Séquence d'action
 Résultat obtenu
Résultat attendu

nécessairement.

------------

Vous n'écrivez pas un essai sur un sujet libre, vous écrivez un texte pour un développeur qui doit comprendre rapidement ce que vous attendez de lui sans aucun détail.

 
sergeev:

tu peux tout faire toi-même, mais

Version du terminal et débit binaire
Description du problème
 Séquence d'action
 Résultat obtenu
Résultat attendu

nécessairement.

------------

Vous n'écrivez pas un essai sur un sujet libre, vous écrivez un texte pour un développeur qui doit comprendre rapidement ce que vous attendez de lui sans aucun détail.

J'ai choisi la section Site mql5.com et la proposition et maintenant je ne comprends pas comment l'attacher aux rubriques.
1...779780781782783784785786787788789790791792793...3184
Nouveau commentaire