[OCILIB] [OCI] Fuite mémoire obscure

Version imprimable

Bonjour,

j'écris un module d'accès à oracle pour une application, et ai des fuites de mémoire à chaque accès qui est fait à Oracle, j'accède à une 11g via Ocilib (j'ai intégré le source d'ocilib pour écarter tout doute à ce niveau).

Premier point, j'ai des fuites lors OCI_ConnectionAttach, mais un collègue m'a indiqué que cette fuite est incontournable. Comme elle n'apparait qu'au début, je l'ignore.

Par contre, à chaque appel, j'ai ceci:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [W] MLK: Memory leak of 20 bytes from 1 block allocated in sscoresetserverflag [OraOCIEI11.dll] Distribution of leaked blocks Allocation location HeapAlloc [C:\WINDOWS\system32\KERNEL32.dll] sscoresetserverflag [PATH_TO_BIN\OraOCIEI11.dll] slzgetevar [PATH_TO_BIN\OraOCIEI11.dll] ociepgoe [PATH_TO_BIN\OraOCIEI11.dll] surr_raw_dbgrmmd [PATH_TO_BIN\OraOCIEI11.dll] CsrNewThread [C:\WINDOWS\system32\ntdll.dll] RtlUnicodeStringToInteger [C:\WINDOWS\system32\ntdll.dll] KiUserApcDispatcher [C:\WINDOWS\system32\ntdll.dll] [W] MLK: Memory leak of 12 bytes from 1 block allocated in ss_mem_thread_attach [OraOCIEI11.dll] Distribution of leaked blocks Allocation location HeapAlloc [C:\WINDOWS\system32\KERNEL32.dll] ss_mem_thread_attach [PATH_TO_BIN\OraOCIEI11.dll] sscoresetserverflag [PATH_TO_BIN\OraOCIEI11.dll] slzgetevar [PATH_TO_BIN\OraOCIEI11.dll] ociepgoe [PATH_TO_BIN\OraOCIEI11.dll] surr_raw_dbgrmmd [PATH_TO_BIN\OraOCIEI11.dll] CsrNewThread [C:\WINDOWS\system32\ntdll.dll] RtlUnicodeStringToInteger [C:\WINDOWS\system32\ntdll.dll] KiUserApcDispatcher [C:\WINDOWS\system32\ntdll.dll]
Cette fuite m'ennuie beaucoup plus, car vu le nombre d'appel que fait mon application, et le fait que l'appli tourne en production 24/7, la mémoire risque de manquer. Mon programme prend 4 à 16ko tous les 4 à 10 "select".

J'ai également essayé avec une 10g, c'est pareil. J'avais auparavant fait mes tests en 9i, c'était pire, mon éxécutable prenait 1 mega par minute!
Pour info, j'ai essayé avec un client oracle installé, et avec l'instant client, même punition. :(
Pour la log ci dessus, c'est de l'instant client 11g, dll copié dans le repertoire de mon install.

est il normal qu'il créé autant de threads ?

16/10/2008, 12h50
Vincent Rogier

Salut,

Quel appel OCI provoque l'allocation qui n'est pas désallouée ?

De plus quelle est la version de ocilib utilisée ?

Et tu est sur que la connexion est bien fermée ?

Utilises tu des pools de connexion ?
16/10/2008, 14h31
zifox

Merci d'avoir lu mon post si vite !

Citation:

Envoyé par vicenzo

Salut,

Quel appel OCI provoque l'allocation qui n'est pas désallouée ?

Et bien justement c'est mon problème, je n'arrive pas à le déterminer ! Comme le montre l'extrait de log de Purify, ca remonte dans ntdll.dll, mais je n'arrive pas à comprendre comment une fonction d'oracle peut découler d'un appel à "RtlUnicodeStringToInteger".

Comme j'ai le problème à chaque requête, j'ai commencé à descendre fonction par fonction pour voir à quel niveau la fuite apparaissait, en déclenchant un "select" sur la base.
J'ai d'abord vu que la fuite apparaissait même sans éxecuter le statement, (et donc sans fetch), il ne restait plus que le OCI_StatementCreate. J'en ai déduit ensuite que cela devait se passer dans la partie OCI_StatementInit.
Et là grosse surprise, je mets un point d'arrêt dedans , rédémarre mon executable, vérifie les fuites sous purify avant même que le programme fasse une requête, et j'ai déjà cette fuite qui apparait dans le listing.
Donc forcément je comprends plus du tout. 8O

J'ai l'impression que la fuite apparait à chaque fois qu'un appel est fait, quel que soit cet appel. :koi:

Citation:

Envoyé par vicenzo

De plus quelle est la version de ocilib utilisée ?

J'utilise la 2.5.1.

Citation:

Envoyé par vicenzo

Et tu est sur que la connexion est bien fermée ?

Utilises tu des pools de connexion ?

Je n'utilise pas de pool de connexion.

De quelle connexion parles tu ? En gros dans mon code, j'ai plusieurs threads, qui ouvrent chacun une connexion sur le serveur. Chaque connexion est fermée à l'arrêt du thread, quand le programme est arrêté.
16/10/2008, 14h59
Vincent Rogier

je te conseille de récupérer la 3.0.0 et de tester avec la 3.0.0.

Si cela continue, j'ai éventuellement une piste en tête et dans ce cas, je t'enverrais une 3.0.0 avec la modif à laquelle je pense.

Tiens moi au courant.
16/10/2008, 15h47
zifox

Ok merci pour tes conseils.

J'ai fait un tour sur le site d'ocilib juste après avoir posté, j'ai vu que la trois était sortie, je l'ai déjà récupérée mais il me faut un peu de temps pour modifier mon makefile ( oldschool powaaa ).
16/10/2008, 15h51
Vincent Rogier

Si avec la 3.0.0 du site, ca change rien, envoie moi un mail (adresse dans les sources)

En retour je t"enverrai une archive 3.0.0 modifiée... pour tester mon idée.

Si cette version modifiée ne change rien, c'est que le souci n'est pas lié à OCILIB...

tiens moi au courant.
16/10/2008, 16h00
zifox

Je te tiens au courant dès que possible, c'est en train de compiler.

J'ai vu ça "- Fixed : Memory leak : internal connection transaction handle was never freed" dans les logs, je suis optimiste ! :)
16/10/2008, 16h16
Vincent Rogier

hé ben, ca compile :mouarf:....
16/10/2008, 16h30
zifox

Ca n'a pas compilé du premier coup, il a fallu que je modifie OCI_CDT_NUMERIC...

et comme mon application mets environ 20 minutes à compiler, j'ai le temps d'aller prendre plusieurs café. :mrgreen:
16/10/2008, 16h33
Vincent Rogier

Bon tu me tiens au courant...
16/10/2008, 17h20
Vincent Rogier

Ca compiles toujours ??
16/10/2008, 17h33
zifox

Bon, ca va me prendre un peu plus de temps que prévu, j'ai maintenant des soucis de connexion. La fonction de check de connexion renvoie toujours false, et j'ai une exception qui casse tout si je l'ignore. :cry:

Faut que je vois d'où ça vient.
17/10/2008, 09h59
zifox

Je t'ai envoyé un mail, j'ai toujours le même problème. :cry:
17/10/2008, 10h48
Vincent Rogier

Pour info, la fuite mémoire semble être liée à OCI qui initialisé en mode multithread, monitore les créations de thread natifs crées au sein de l'application.

OCI alloue quelques octets pour stocker des infos lié à chaque thread et apparemment ne les rends pas...

Je pense ouvrir un ticket sur metalink pour ca...
17/10/2008, 17h25
zifox

J'en ai ouvert un cet après midi, je posterai des réponses sur ce problème dès que j'en aurai !

Merci encore Vincent!
09/12/2008, 11h42
zifox

Cela fait deux mois que j'ai ouvert un dossier chez Oracle, ils ont vu qu'il y avait un souci, mais je n'ai pas de réponse quant à une correction pour le moment.

Faut pas être pressé avec eux.
22/12/2008, 15h14
zifox

Oracle a fermé le dossier ce matin, disant qu'ils n'arrivaient pas à reproduire... contrairement au message précédent qui disait qu'ils avaient bien vu les fuites... :arf:

J'ai rouvert le dossier... à mon avis la réponse va pas être rapide à arriver. :(
28/01/2009, 17h47
zifox

Dernière mise à jour pour cette histoire.

La fuite est toujours là, le support oracle, malgré les traces de Rational "refuse de reconnaitre la fuite". Texto "it's not a real leak".
Ca c'en est une, soit c'en est pas ! :evilred:
Enfin bref, ils ne feront rien.

J'ai mis à jour mon client, résultat, j'ai une fonction de plus qui apparait dans la trace comme source de fuite: "sqlxads".

Le monsieur du support m'a dit qu'il fallait fermer le lien à Oracle dès qu'on peut et que si je ferme mon appli, au bout de quelques minutes la mémoire se nettoiera. Très professionnel comme manière de procéder... Quand l'appli doit tourner 24/24 et faire tourner une production, on fait comment ?

J'étais déjà pas très Oracle, après cette histoire je suis vraiment contre !

Ma boite va essayer de faire monter la gravité du bug pour voir si ça bouge... David vs Goliath. :mrgreen:
02/08/2010, 16h22
yves042

Bonjour,

je réactualise cette discussion pour savoir si un correctif d'oci a été réalisé ou si la fuite mémoire est toujours présente.

Merci.
02/08/2010, 17h06
Vincent Rogier

aucune idée...:(