Discussion :

[zifox]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[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 ?

[zifox]

Merci d'avoir lu mon post si vite !

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.

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

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

J'utilise la 2.5.1.

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é.

[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.

[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 ).

[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.

[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 !

[Vincent Rogier]

hé ben, ca compile ....

[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é.

[Vincent Rogier]

Bon tu me tiens au courant...

[Vincent Rogier]

Ca compiles toujours ??

[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.

Faut que je vois d'où ça vient.

[zifox]

Je t'ai envoyé un mail, j'ai toujours le même problème.

[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...

[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!

[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.

[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...

J'ai rouvert le dossier... à mon avis la réponse va pas être rapide à arriver.

[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 !
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.

[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.

[Vincent Rogier]

aucune idée...