Re: [Orclib-users] possible bug in ocilib

[David N. <da...@qo...>]

Hi Vincent,

ok no problem.

Since we normally program in C++ (when we're not programming in Qore! :) ), I see ocilib as being a ideal candidate for having a very nice c++ API that could greatly simplify the function calls and additionally be safer to use (regarding resource/memory management with RAII).  This could potentially be built on top of any new (or the existing) C API for ocilib (ideally I would also like to export a C API for Qore - it was always my plan - but I never got around to it).

I would personally love to see an updated version of ocilib that supports multiple environment handles; it would make it much easier to track further development of ocilib.

Basically we have taken ocilib and modified every single function to accept an "OCI_Library* pOCILib" argument as the first arg and removed the global variable of this name entirely.  Supporting multiple environment handles I would think would be a must for any more complex use case (or generalized export of your API to a programming language, for example like with Qore).  Anyway, we need it, and thanks to the power of open source and your great lib, we have it...

Whatever you decide; ocilib remains a great library and a huge benefit to the oracle driver in Qore.

thanks,
David


On Jun 21, 2012, at 3:47 PM, vincent rogier wrote:

> Hi,
> 
> Thanks for reporting it. This issue has been identified recently and the upcoming 3.9.4 release (not the one on the svn) already has a fix for it :).
> 
> I know that you using a modified version because ocilib does not support multiple environment and charsets...
> Many times, i thought about fixing this but it will have to break the backward compatibility with previous versions...
> since version 1.0.0, i kept backward compatibility as a major goal. And i still have to deal with early design errors ....
> I was thinking to create a 4.x branch with some changes in the design and keep on supporting 3.x....
> But is worth it ? i don't know...
> 
> Best regards,
> 
> Vincent
> 
> 
> On Thu, Jun 14, 2012 at 10:48 AM, David Nichols <da...@qo...> wrote:
> Hi there,
> 
> I've found what appears to me to be a bug in ocilib - also in svn trunk.
> 
> The problem is in OCI_TypeInfoGet() - if the function fails to get a description for an object, the function returns NULL, however a list entry in con->tinfs is left there anyway - it happens like this (the line numbers below correspond to ocilib in svn trunk as of the time this email was written):
> 
> typeinfo.c:185: the list entry for the OCI_TypeInfo object is created:
>        item = OCI_ListAppend(pOCILib, con->tinfs, sizeof(OCI_TypeInfo));
> 
> typeinfo.c:417: checks to see if a description was retrieved; if not, the return value is set to NULL, however the list entry is not removed
>    if (res == FALSE)
>    {
>       OCI_TypeInfoFree2(pOCILib, typinf);
>       typinf = NULL;
>    }
> 
> typeinfo.c:160:  if OCI_TypeInfoGet() is called again, then the list entry with the invalid description is found and a non-NULL return value is returned:
>    item = con->tinfs->head;
> 
>    /* walk along the list to find the type */
> 
>    while (item != NULL)
>    {
>        typinf = (OCI_TypeInfo *) item->data;
> 
>        if ((typinf != NULL) && (typinf->type == type))
>        {
>            if ((mtscasecmp(typinf->name,   obj_name  ) == 0) &&
>                (mtscasecmp(typinf->schema, obj_schema) == 0))
>            {
>                found = TRUE;
>                break;
>            }
>        }
> 
>        item = item->next;
>    }
> 
> 
> my fix was to change the logic @ typeinfo:417 to remove the value from the list if the calls to get the object description failed and NULL is returned:
>    if (res == FALSE)
>    {
>       OCI_TypeInfoFree2(pOCILib, typinf);
>       /* delete item from item list */
>       if (found == FALSE)
>          OCI_ListRemove(pOCILib, con->tinfs, item->data);
>       typinf = NULL;
>    }
> 
> This scenario may not be important to some people - but it is in the way we use ocilib (as a helper library for the Oracle driver for Qore - qore.org)
> 
> unfortunately we cannot easily track ocilib trunk because we had to heavily modify ocilib to support multiple environment handles, however we try to sync upstream fixes, and will always try to feed back any issues we find to the upstream project.
> 
> thanks for making such a great library!
> 
> thanks,
> David
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Orclib-users mailing list
> Orc...@li...
> https://lists.sourceforge.net/lists/listinfo/orclib-users
> 
> 
> 
> -- 
> Vincent Rogier