Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Comme le titre indique, Dans mon code PB je boucle sur une datawindow de 3700 lignes (dans la boucle il y a des maj dans la datawindow elle même).
Quand je lance la génération, il y a un crash dans l'application(affichage d'un message Sybase puis je clique sur don't send) et précissement dans cette boucle FOR, mais c'est aléatoire.
Version PB: PowerBuilder 10.5.1 Build 6684.
Oracle 10g
OS : XP 2002, SP3
J'ai cherché sur le net et dans les EBF mais j'ai rien trouvé.
Est-ce quel qu'un a rencontré ce problème ? Ce bug a été corrigé dans un EBF ?
Merci d'avance.
Hors ligne
Salut,
Tu sautes peut-être un peu vite sur la solution "bug Sybase" ;-)
Si tu veux de l'aide, il faudrait peut-être que tu indiques clairement LE message d'erreur et le contexte.
Tu dis lancer la génération : est-ce à dire que ça plante lors d'une compilation ?
Hors ligne
General Protection Fault a écrit:
Salut,
Tu sautes peut-être un peu vite sur la solution "bug Sybase" ;-)
Si tu veux de l'aide, il faudrait peut-être que tu indiques clairement LE message d'erreur et le contexte.
Tu dis lancer la génération : est-ce à dire que ça plante lors d'une compilation ?
Désolé, j'ai mal exprimé. Je voulais dire par le mot génération : dans mon écran il y a un bouton GENERE qui permet de générer un état (un rapport).
Voici ci-dessous les messages qui s'affichent :
Quand je clique sur CLICK HERE
Hors ligne
essaye en mode debug, ligne par ligne, tu verras bien ce qui fait planter...
Hors ligne
erasorz a écrit:
essaye en mode debug, ligne par ligne, tu verras bien ce qui fait planter...
Plutot, j'ai lancé le trace sur le code powerbuilder... et puisque le bug est aléatoire et après plusieurs tentative, j'ai catché la fonction ou il crash. C'est au niveau d'une fonction implémenter dans une DLL.
Mais le problème c'est que on a pas le code source de cette DLL
Je dois chercher un outil pour décoder cette DLL...
Hors ligne
Une DLL... Donc GPF avais bien raison de dire ça :
General Protection Fault a écrit:
Tu sautes peut-être un peu vite sur la solution "bug Sybase" ;-)
Elle fait quoi cette DLL ?
Tu ne lui envoies pas un argument NULL par hasard, ou une chaine non prédéfinie par un Space(N) ?
Hors ligne
erasorz a écrit:
Une DLL... Donc GPF avais bien raison de dire ça :
General Protection Fault a écrit:
Tu sautes peut-être un peu vite sur la solution "bug Sybase" ;-)
Elle fait quoi cette DLL ?
Tu ne lui envoies pas un argument NULL par hasard, ou une chaine non prédéfinie par un Space(N) ?
C'est notre DLL dévéloppée depuis les années 90. Elle permer de chercher une valeur dans une table je crois.
Effectivement, je suis en train de tracer les parametres passés à cette fonction (il y a environ 11 parametres...
S'il s'agit d'une histoire des arguments, tu peux me dire pourquoi le message ne s'affiche pas toujours (aléatoire) ?
Dernière modification par mattdamon (21-10-2010 13:42:04)
Hors ligne
À première vue, je dirais comme erazorz que l'erreur vient d'une valeur chaîne non pré-initialisée.
Si tu n'initialises pas (par exemple avec un space()) la variable côté PB avec la taille maximum possible, un débordement de buffer se produira. Il sera plus ou moins important en fonction de la taille de la chaîne passée en paramètre... Selon le code écrasé, ça peut donc planter tout de suite, un peu plus tard, voire pas du tout.
Hors ligne
FMolinas a écrit:
À première vue, je dirais comme erazorz que l'erreur vient d'une valeur chaîne non pré-initialisée.
Si tu n'initialises pas (par exemple avec un space()) la variable côté PB avec la taille maximum possible, un débordement de buffer se produira. Il sera plus ou moins important en fonction de la taille de la chaîne passée en paramètre... Selon le code écrasé, ça peut donc planter tout de suite, un peu plus tard, voire pas du tout.
Bonsoir,
Vraiment, j'ai rien compris...
J'ai écri un pétit code qui permet d'écrire dans un fichier les arguments passés à la fonction de la DLL.
Les parametres passés avant crash :
le user = user1
l'atome = xxxx
l'operation = 505210
l'evenement = 0
le reglement = 0
le null flag =
le string value =
la date paremetre = jj/mm/aaaa
le long value = 0
le ok = 0
le double value = 0
Les parametres passés et causent le crash :
le user = user1
l'atome = xxxx
l'operation = 505210
l'evenement = 0
le reglement = 0
le null flag =
le string value =
la date paremetre = jj/mm/aaaa
le long value = 0
le ok = 0
le double value = 0
S vous remarquez que les parametres de dernier appel et les parametres de l'appel avant dernier sont les mêmes. La question qui se pose : pourquoi le crash dans le 2 et pas dans le premier sachant que les mêmes parametres qui sont passés à la fonctions ?
Vraiment c'est bizarre...
Hors ligne
mattdamon a écrit:
La question qui se pose : pourquoi le crash dans le 2 et pas dans le premier sachant que les mêmes parametres qui sont passés à la fonctions ?
Euh, difficile de répondre sans une boule de cristal...
Comme le dit FMolinas : "Selon le code écrasé, ça peut donc planter tout de suite, un peu plus tard, voire pas du tout."
mattdamon a écrit:
C'est notre DLL dévéloppée depuis les années 90. Elle permer de chercher une valeur dans une table je crois.
Sinon, y'a vraiment besoin d'une DLL pour ça ?
Hors ligne
erasorz a écrit:
mattdamon a écrit:
La question qui se pose : pourquoi le crash dans le 2 et pas dans le premier sachant que les mêmes parametres qui sont passés à la fonctions ?
Euh, difficile de répondre sans une boule de cristal...
Comme le dit FMolinas : "Selon le code écrasé, ça peut donc planter tout de suite, un peu plus tard, voire pas du tout."mattdamon a écrit:
C'est notre DLL dévéloppée depuis les années 90. Elle permer de chercher une valeur dans une table je crois.
Sinon, y'a vraiment besoin d'une DLL pour ça ?
C'est une DLL écrit en C, je crois que l'idée d'écrire en C et pas en PB c'est pour avoir un temp de traitement plus rapide (C très proche de langage machine) et en plus on fait appel très fréquents à cette DLL.
Le problème c'est que je connais pas le code écrit dans cette DLL pour pouvoir l'écrire en PB!!!
D'après votre analyse, c'est quoi l'origine de problème ? Quel solution de contournement vous proposez ?
Merci d'avance pour votre aide.
Dernière modification par mattdamon (22-10-2010 09:10:22)
Hors ligne
J'ai oublié de citer que l'appel à la fonction de la DLL est très très fréquents...
D'après vous une GarbageCollect() juste avant l'appel à la fonction peux corriger le problème. Je suis sûre qu'il s'agit d'une histoire des variables + mémoires.
Dernière modification par mattdamon (22-10-2010 09:55:01)
Hors ligne
Bonjour,
Est-ce que c'est possible de savoir le problème en faisant try...catch lors de l'appel de la fonction de la DLL
Quelqu'un peux m'aider de le faire...
c'est comme ici :
http://pbadonf.fr/forum/viewtopic.php?pid=23768#p23768
Hors ligne
Salut,
Qu'est ce qui t'empêche d'essayer d'appeler GarbageCollect() juste avant l'appel à la fonction ? Tu auras une réponse plus rapide que via le forum tu sais ;-)
idem pour trapper une exception.
Maintenant, si tu n'as pas essayé les suggestions proposées un peu plus tôt... Essaie donc d'initialiser toutes les Strings que tu passes à ta fonction/DLL avant l'appel de la façon suivante :
ls_param1 = Space(2048) ls_param2 = Space(2048) ls_param3 = Space(2048) li_ret = myDLL_FunctionToto( ls_param1, ls_param2, ls_param3)
Hors ligne
mattdamon a écrit:
D'après votre analyse, c'est quoi l'origine de problème ? Quel solution de contournement vous proposez ?
Comme je le disais succinctement plus haut, il faut pré-initialiser tous les paramètres de type chaîne passés à la fonction C. En particulier les chaînes en paramètre de retour... La fonction C ne fait pas de malloc(), elle suppose que l'appelant (ici PB) a déjà réservé l'espace nécessaire.
Dans ta liste de paramètres, je vois un "string value" sans valeur. Tente un "string_value = space(255)" avant d'appeler la DLL. Et pareil avec "null_flag = space(1)" si ton flag est de type chaîne.
Et pour moins tâtonner de notre côté, peux-tu poster la ligne qui déclare ta fonction de DLL dans PB ? Je parle de celle qui se trouve dans la section Local (ou Global) External Functions, et qui annonce quelque chose du genre : "Function uint MaFonction (long handle, ref string fait_planter) Library "MaDll.DLL"".
Hors ligne
FMolinas a écrit:
mattdamon a écrit:
D'après votre analyse, c'est quoi l'origine de problème ? Quel solution de contournement vous proposez ?
Comme je le disais succinctement plus haut, il faut pré-initialiser tous les paramètres de type chaîne passés à la fonction C. En particulier les chaînes en paramètre de retour... La fonction C ne fait pas de malloc(), elle suppose que l'appelant (ici PB) a déjà réservé l'espace nécessaire.
Dans ta liste de paramètres, je vois un "string value" sans valeur. Tente un "string_value = space(255)" avant d'appeler la DLL. Et pareil avec "null_flag = space(1)" si ton flag est de type chaîne.
Et pour moins tâtonner de notre côté, peux-tu poster la ligne qui déclare ta fonction de DLL dans PB ? Je parle de celle qui se trouve dans la section Local (ou Global) External Functions, et qui annonce quelque chose du genre : "Function uint MaFonction (long handle, ref string fait_planter) Library "MaDll.DLL"".
Merci à tous de votre retour.
Voici la déclaration :
FUNCTION int Chercher_atome(string utilisateur, string atome, long operation, long evenement, long reglement,ref string null_flags, ref string string_value, ref string date_value, ref long long_value, ref int boolean_value, ref double double_value) LIBRARY "ma_dll.dll" ALIAS FOR "Chercher_atomex;Ansi"
ci-dessous l'appel à la fonction :
retour = Chercher_Atome (user, code.atome, mem_operation, mem_evenement, mem_reglement, & null_flags, resultat.string_value, date_parametre, resultat.long_value, & ok, resultat.double_value)
Coté déclaration des parametres : je vois que tous les variables passées à la fonction sont initialisées sauf null_flags et code.atome.
Je viens de initialisés ces deux parametres comme suit :
null_flags = Space(1)
IF IsNull (code.atome) THEN code.atome = Space(200)
Je suis en train de tester cette solution, je vous tiens au courant dès que je trouve un résultat.
Dernière modification par mattdamon (22-10-2010 16:30:51)
Hors ligne