[Orclib-users] possible bug in ocilib

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

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