Discussion :

[zifox]

Bonjour,
je pose la question suivante par pure curiosité:

Je viens de me rendre compte d'un truc que je ne comprends pas avec les OCI.
Initialement quand j'ai commencé mon projet, j'ai posé à coté de mon executable, oci.dll, ociw32.dll et oraociei11.dll.

Juste après démarrage, mon éxecutable faisait 33Megas.

Suite à des crash systématique au démarrage de mon appli au fin fond d'oraociei11, j'ai viré les deux autres petites dll, puisque mon programme linke directement avec oraociei11.

Suite à cette suppression, non seulement je n'ai plus de crash au lancement, mais en plus mon éxecutable ne fait plus que 13 megas !

Quelqu'un à une explication à ce phénomène ?

[zifox]

Je pense avoir un partie de la réponse: vu qu'il ne trouve pas les dlls, il doit utiliser celle de l'install de mon client complet.
Donc aussi bizarre que cela paraisse, avec l'oci.Dll de l'instant client 11, j'ai un crash au fin fond de oraociei11, soit sur un HandleAlloc soit sur un free, alors que je ne l'ai pas avec l'oci.dll de mon client 9i.

[Vincent Rogier]

Tu utilises quel compilo ?

Tu ne doit pas linker directement oraociei11.dll !!!

tu dois linker uniquement avec oci.dll (qui s'occupe de charge en dynamique oraociei11.dll, mais ca c'est sa popote à lui !)

De plus, on ne linke pas une dll mais une librairie d'import (.*lib).

Donc tu dois linker oci.lib uniquement

[zifox]

J'utilise gcc et ne link qu'avec oci.lib.

En fait j'ai mal interprété ce qui se passait.

Quand j'enlève oci.dll et ociw32.dll de mon répertoire de binaire, il utilise en fait le oci.dll de mon install client 9i, qui lui va chercher les dlls dans l'install 9i, donc en fait j'utilise pas du tout la dll de la 11g.
J'avais pas compris qu'oci.dll était le point d'entrée, et non pas oraociei11.

J'ai installé un client 11g complet, et je reproduis le même problème à un détail près:

mon appli sort toujours, avec un message d'erreur ORA-24550 une fois sur trois (je pense que je ne le vois pas s'afficher mais il doit etre toujours là), mais par contre elle ne crash plus comme elle le faisait avant.

[Vincent Rogier]

peut poster la partie du makefile concernée ?

[zifox]

Voici ma ligne de link, je vous fait grace de la liste des objets.

link -nologo -incremental:no libcmtd.lib oldnames.lib wsock32.lib kernel32.lib user32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib uuid.lib psapi.lib -DEBUG -NODEFAULTLIB:LIBC -NODEFAULTLIB
:LIBCMT -NODEFAULTLIB:LIBCMTD -NODEFAULTLIB:msvcrt -fixed:no -opt:ref -out:exec_name

[liste des objs]
y:/dist/mysql/lib/nt40_mt/libmysql.a y:/dist/oracle/lib/nt40_mt/oci.lib y:/dist/ssllib/lib/nt40_mt/libeay32.lib y:/dist/ldaplib/lib/nt40_mt/nsldap32v50.lib
y:/dist/ref/zlib/1.1.3/nt40_mt/libz.a

[liste de lib "internes"]


edit: je retire sur ce que je dis sur l'absence de crash, ça vient de peter.

[zifox]

Problème résolu, à fermer.

Quelques explications et comportements:

Après avoir installé un client complet 11G et supprimé l'instant client, j'avais des soucis aléatoirement au démarrage, soit l'application quittait sans rien dire, soit je recevais:
ORA-24550: signal received: Unhandled exception: Code=c0000005 Flags=0

ou encore
KPEDBG_HDL_PUSH_FCPTRMAXKPEDBG_HDL_PUSH_FCPTRMAX

soit fonctionnait très bien. Comme si une fois une phase critique passée, ça fonctionnait.

J'ai bidouillé avec les options d'init d'OCI, et ai solutionné le problème en mettant OCI_ENV_THREADED.

Problème résolu donc, seule un flou reste: pourquoi cela ne plantait QUE sur MA machine ?

[Vincent Rogier]

Donc, tu avais une appli multithread en initialisant OCILIB (et donc OCI) en single thread ?

Normal que cela ne marchait pas trop

Pourquoi que sur ta machine ? Ma foi, dieu seul sait...

Est ce que c'était réellement spécifique à ta machine ?
ou alors en fonction de la logique applicative de ton prog ?
ou lié au couple runtime microsoft / oci.dll ou version OS / Oracle, etc ..?

L'essentiel, c'est que cela fonctionne bien...

au fait, petite question : pourquoi tu compile le source d'OCILIB dans l'appli au lieu d'utiliser la dll ?

Pour infos, la v3.1.0 de OCILIB va être releasée dans quelques jours...

[zifox]

Donc, tu avais une appli multithread en initialisant OCILIB (et donc OCI) en single thread ?

Normal que cela ne marchait pas trop

Pourquoi que sur ta machine ? Ma foi, dieu seul sait...

Est ce que c'était réellement spécifique à ta machine ?
ou alors en fonction de la logique applicative de ton prog ?
ou lié au couple runtime microsoft / oci.dll ou version OS / Oracle, etc ..?

L'essentiel, c'est que cela fonctionne bien...

C'est ça que je n'arrive pas à m'expliquer, pourquoi que sur ma machine, et pourquoi cela marchait au début ? J'étais parti du principe que la connexion n'étant pas partagée entre plusieurs threads, je n'avais pas besoin de ce flag.
Et ben en fait non.
Il est aussi possible, mon poste étant une machine de dév, que j'ai plusieurs trucs installés qui déclenchent le problème.
Quand je passerai en phase de test j'essaierai avec et sans le flag voir si ça pose problème sur une autre machine.

au fait, petite question : pourquoi tu compile le source d'OCILIB dans l'appli au lieu d'utiliser la dll ?

Pour infos, la v3.1.0 de OCILIB va être releasée dans quelques jours...

Pour ne pas avoir à compiler ocilib à coté sous unix et linux. J'ai 7 plates formes potentielles à générer, c'est plus simple de les rajouter le makefile global.

[Vincent Rogier]

Pour ne pas avoir à compiler ocilib à coté sous unix et linux. J'ai 7 plates formes potentielles à générer, c'est plus simple de les rajouter le makefile global.

Bonne raison ! mais qui t'oblige à relinker ton appli entière si pour une raison X tu veux upgrader la version d'OCILIB...

[zifox]

Bonne raison ! mais qui t'oblige à relinker ton appli entière si pour une raison X tu veux upgrader la version d'OCILIB...

C'est un moindre mal, il n'y a pas de bug dans la librairie qui pousse à changer de version.

[Vincent Rogier]

C'est un moindre mal, il n'y a pas de bug dans la librairie qui pousse à changer de version.

c'est vrai que c'est une super lib codée par un super mec qui fait du super code

[zifox]

c'est vrai que c'est une super lib codée par un super mec qui fait du super code

Ca va les chevilles ?
Tu veux des moonboots à Noel ?

[Vincent Rogier]

Ca va les chevilles ?
Tu veux des moonboots à Noel ?

si on peut même plus déconner un peu de temps en temps ...

[zifox]

si on peut même plus déconner un peu de temps en temps ...

Tu pourrais cacher des cadeaux dans la prochaine release, prévue pour... disons noël ?

Aléatoirement tu renvoie un recordset avec une entrée en plus avec "Vicenzo, c'est plus fort que toi.", "Santa Claus, powered by Ocilib".

[Vincent Rogier]

la dernière mouture de la version 3.1.0 est dispo sur le svn de ocilib...

La release est effectivement prévue pour noel

Changelog de la v3.1.0 :

2008-xx-xx Version 3.1.0 Vincent Rogier vince.rogier@gmail.com

* Added support for Oracle REF datatype

- Added OCI_RefCreate()
- Added OCI_RefFree()
- Added OCI_RefGetObject()
- Added OCI_RefAssign()
- Added OCI_RefIsNull()
- Added OCI_RefSetNull()
- Added OCI_RefToText()
- Added OCI_RefGetHexSize()
- Added OCI_GetRef2()
- Added OCI_GetRef()
- Added OCI_BindRef()
- Added OCI_BindArrayOfRefs()
- Added OCI_RegisterRef()
- Added OCI_ElemGetRef()
- Added OCI_HandleGetRef()
- Added OCI_ObjectGetRef()
- Added OCI_ObjectGetSelfRef()

* Added some tracing features

- Added OCI_SetTrace()
- Added OCI_GetTrace()

* Extended Object API

- Fixed internal handling of null attributes (it has been rewritten)
- Modified local (transients) objects creation. Now :

* By default, all attributes are set to NULL
* Non scalar attributes must be set by calling new functions OCI_ObjectSetXXX()

- Added setters functions for non scalar object attributes

* OCI_ObjectSetDate
* OCI_ObjectSetInterval
* OCI_ObjectSetTimestamp
* OCI_ObjectSetColl
* OCI_ObjectSetObject
* OCI_ObjectSetFile
* OCI_ObjectSetLob
* OCI_ObjectSetRef

- Added Miscellaneous Object functions

* Added OCI_ObjectIsNull()
* Added OCI_ObjectAssign()
* Added OCI_ObjectGetType()

* Extended Collection elements API

- Fixed : OCI_ElemSetNull() that was only udpating null indicator
- Fixed : some functions were not checking input elem handle nullity
- Added checks on element type in OCI_ElemGetXXX() calls that throw an exception if the element type is not the same type as the one requested
- Added setters functions for non scalar element base datatypes

* OCI_ElemSetDate()
* OCI_ElemSetInterval()
* OCI_ElemSetTimestamp()
* OCI_ElemSetColl()
* OCI_ElemSetObject()
* OCI_ElemSetFile()
* OCI_ElemSetLob()
* OCI_ElemSetRef()

* Extended Bind informations

- Modified : OCI_Bind handles are now public and can be retrieved for public information
- Added OCI_GetBindCount()
- Added OCI_GetBind()
- Added OCI_GetBind2()
- Added OCI_BindGetName()
- Added OCI_BindGetType()
- Added OCI_BindGetSubtype()
- Added OCI_BindGetStatement()
- Added OCI_BindGetData()
- Added OCI_BindGetDataCount()
- Added OCI_BindGetDataSize()
- Added OCI_BindGetDataSizeAtPos()
- Added OCI_BindSetDataSize()
- Added OCI_BindSetDataSizeAtPos()
- Added OCI_SetNull2()
- Added OCI_SetNullAtPos2()
- Extended OCIBindxxx() calls satefy :

* An error OCI_ERR_BIND_ALREADY_USED is now raised if the bind name or position is already binded to the statement
* With the bind mode by position, provided bind indexes <= 0 and > OCI_BIND_MAX will cause an error OCI_ERR_OUT_OF_BOUNDS

- Extended binds/registers limits :

* OCI implements the SQL returning clause through binds operations
* OCILIB wraps the result of the returning clause within OCI_Resultet object but has to use internal binds to create its resultset
* Prior to v3.1.0, OCI_BIND_MAX (default 512) was the maximum of OCI_bindxxx() including OCI_Registerxxx() that an OCI_Statement could handle
* With v3.1.0, OCILIB can handle OCI_BIND_MAX user binds handle and OCI_BIND_MAX items in the returning clause

* Fixed Unicode support for Unixes platforms

* Unicode support for platforms with 4 bytes wchar_t was broken
* Fixed configure script was setting bad charset macros
* Fixed some internal buffer expansion functions

* Miscellaneous public modifications

- Added OCI_IsNull2()
- Added OCI_ResultsetGetStatement()
- Added OCI_BindArrayOfColls()

- Added functions to retrieve OCI_Schema object from various OCILIB object bases on Oracle object type :

* Added OCI_ObjectGetSchema()
* Added OCI_CollGetSchema()
* Added OCI_RefGetSchema()

- Added runtime information about OCILIB builds modes :

* Added OCI_GetImportMode()
* Added OCI_GetCharsetMetaData()
* Added OCI_GetCharsetUserData()

- On Oracle versions >= 11g, OCILIB now sets the client driver layer name information

* Value set to the constant OCILIB_DRIVER_NAME (by default "OCILIB")
* It's recorded in the system views V$SESSION_CONNECT_INFO and GV$SESSION_CONNECT_INFO

- Modified ocilib demo to properly support MinGw and unix based unicode console output

* Miscellaneous internal modifications

- Added internal reference counter to OCI_Schema object

* Some OCILIB objects keep a pointer to a some OCI_schema objects
* If OCI_SchemaFree() was called, these objects were holding a reference to a freed block of memory and then accessing this reference could cause a segfault
* Now OCI_SchemaFree() only frees an schema object if its reference counter is zero.

* Miscellaneous fixes

- OCI_IsConnected() was always returning FALSE since v3.0.0
- OCI_SchemaGet() with OCI_SCHEMA_TABLE was causing an ORA-24328 with Oracle 8 and 9 (working fine with Oracle 10) since v3.0.0
- Fixed demo file output.c
- Fixed some preprocessor directives in oci_loader.h
- OCI_Fetchxxx() functions could return TRUE even if the given SQL statement had some SQL conversion function that failed (like to_date(), etc..)
- OCI_Getxxx() functions could cause a segfault called before any OCI_Fetchxxx() calls
- Fixed OCI_Object reusability: internal sub object could not be freed when fetching next object and thus lead to memory leaks
- Since v3.0.0, fetching LONG column with OCI_LONG_IMPLICIT mode was truncating data to its half length in Unicode and Mixed Builds
- Fixed some prepocessor directives for MinGw support
- Fixed runtime loading of oracle libs that might have not worked if the provided OCI library location ended with an existing slash
- Fixed internal OCI_CopyString() that might caused some troubles in unicode builds
- Fixed some internal wrong arrays size used for memmory allocation