Re: [Orclib-users] possible bug in ocilib

[vincent r. <vin...@ya...>]

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