Bonjour,

J'ai ce problème symptomatique avec PB 11.2.8542. L'application a également subit différentes migrations : 5,7,9,11.

J'ai des crashs identiques sur les postes sollicitants beaucoup l'impression (bons de livraisons, factures, ....). Il va falloir que je travaille également sur le problème ça commence à énerver les utilisateurs.

La fréquence des crashs est fortement dépendante du type d'imprimante. Déjà, il semble que l'utilisation du tout dernier drivers d'imprimante améliore les choses (sur HP utilisation du PCL5e au lieu de PCL6 améliore les choses).

Je ne constate effectivement aucun problème sur les postes de développement. Mais, je ne sollicite pas l'impression comme un utilisateur final.

Par contre, la configuration du poste peut être un début de piste. C'est effectivement les postes les plus anciens de la société sur lesquels se produisent les problèmes donc les moins biens pourvus matériellement.

Le problème est le caractère aléatoire du problème qui m'empêche de lancer l'application en mode /PBDEBUG pour identifier la ligne de code à l'origine du problème.

Je n'utilise pas les derniers EBF PB 11.2 car des régressions ne me permettent plus de compiler en automatique avec ORCA.

Bonjour,

Si tu oublies de pré-initialiser les variables, ça ne pardonne pas, le GPF est immédiat.

Je songe plutôt à une fuite mémoire avec un DESTROY manquant quelque part comme début de piste.

foon a écrit:

Autre piste à explorer en cas de fuite mémoire: les objets OLE.
Quand tu utilises des instructions OLE, pense à invoquer le garbage collector
régulièrement dans ton code.

Même sans OLE. Avec PB11.5.1 Build 4566 je viens de résoudre un problème de plantage "aléatoire" en ajoutant une instruction GarbageCollect() dans une boucle for...next existante (où il n'y avait pourtant aucun create)

J'ai également constaté qu'en déclarant un tableau à dimension variable en instance d'un objet. Si on l'initialise à la déclaration, alors PB ajoute un item vide de façon aléatoire lors de l'utilisation.

// Déclaration
string is_mon_tableau = {"val1","val2","val3"}


// Dans le code de l'objet

// upperbound(is_mon_tableau[]) = 3
// plusieurs instructions plus loin sans manipuler le tableau...
// upperbound(is_mon_tableau[]) = 4

buck a écrit:

Si tu oublies de pré-initialiser les variables, ça ne pardonne pas, le GPF est immédiat.

C'est ce que je pensais aussi... Mais par expérience, ce n'est pas toujours immédiat, d'où ma note.