LONG RAW problem in Digital UNIX system using Pro*C

From: Clayton M. Arends <nospam_carends_at_evisions.com>
Date: 2000/05/12
Message-ID: <LiYS4.4619$bt1.22641@typhoon1.san.rr.com>#1/1

All,

I have a particularly interesting problem on one of my clients' systems. Her server is Digital UNIX running Oracle 8 (I think) though I believe the version may not matter as you will see soon. It is important to note that this program works on all other client systems in a variety of UNIX flavors, VMS, and NT.

Our Pro*C program retrieves data from a BLOB (LONG RAW) field. What happens is we are unable to allocate anymore memory for the program (using malloc or realloc) after a BLOB is retrieved from the table. The problem occurs after the SELECT statement is executed and we make a reference to the Length member of the LONG RAW structure. The actual BLOB being retrieved is 168 bytes so we know it's not an overflow problem. If we print a debug using the Length member then it displays 168 just as it should.

I will include the pertitent snippets from the program.

// -- Header file

// This is the declaration of the LongRaw type
    #define MAX_BLOB_SIZE 2097152
    struct LongRaw
    {

       long Length;
       char Buffer[MAX_BLOB_SIZE];

    }; /* LongRaw */
    typedef struct LongRaw LongRaw;

// This is another LongRaw type for entries that
// can be larger than 2MB

    struct LongVarRaw
    {

       long  Length;
       char  Buffer[10];

    }; /* LongVarRaw */
    typedef struct LongVarRaw LongVarRaw;

// -- C source file

    EXEC SQL TYPE LongRaw is LONG VARRAW (MAX_BLOB_SIZE);     EXEC SQL TYPE LongVarRaw is LONG VARRAW (1073741824) REFERENCE;

    static LongRaw rptBLOBRaw; /* Blob data read from table */

    static char* rptBLOBData;

    EXEC SQL BEGIN DECLARE SECTION;
    EXEC SQL END DECLARE SECTION; // -- Actual SQL statement area
bool SQL_SelectBlobData(int Mode)
{

   EXEC SQL DECLARE selectblobdata_cursor CURSOR FOR

      SELECT EVIBLOB_DATA
        FROM EVIBLOB
       WHERE EVIBLOB_ID = :rptBLOBID OR
             EVIBLOB_EVIBLOB_ID = :rptBLOBID
       ORDER BY EVIBLOB_ID;

   if (Mode == PROCESS_CLOSE_CURSOR)
   {

      debug(1, "   Close Cursor\n", NULL, NULL);
      EXEC SQL CLOSE selectblobdata_cursor;
      POSTORA;
      return true;

   }

   if (Mode == PROCESS_FIRST_ROW)
   {

      debug(1, "   First row\n", NULL, NULL);
      EXEC SQL OPEN selectblobdata_cursor;
      POSTORA;

      if (rptBLOBData)
         free(rptBLOBData), rptBLOBData = NULL;
      rptBLOBLength = 0;

   }

   EXEC SQL FETCH selectblobdata_cursor INTO

      :rptBLOBRaw:Ind_01;
   POSTORA;    if (NO_ROWS_FOUND)

      return false;

   // Fake mallocs to test
// This malloc will work

   rptBLOBData = (char*) malloc(1024);
// This malloc will not, with or without the previous malloc
   rptBLOBData = (char*) malloc(rptBLOBRaw.Length);
// Because of the last malloc, this malloc
// and any future mallocs will not work
   rptBLOBData = (char*) malloc(1024);

   return true;
}
// -- End code snippet

POSTORA is a macro that checks if the return value is < 0 and if so prints an appropriate error message. rptBLOBData is a dynamically allocated chunk of memory that will hold the results of allocation. This routine is called several times by another manager routine that passes a mode flag. One mode for opening the first row, a second mode for each subsequent row, and a third mode to close the cursor. Don't focus on that since the error happens on the first row anyway.

Any insight would be appreciated. Again, the code works on about six other flavors of UNIX, VMS, and NT. It is only this user's system that is giving us a problem and as far as I can see the code is correct. Might it be a configuration issue on their server? The DBA that I've been speaking with knows very little about LONG RAW and therefore might have not installed correct packages, etc. Just a long shot and I seriously doubt it. We have a client application that is Windows based that is adding and reading from the BLOB table with no problems so I don't think it's an Oracle configuration issue.

Thanks,
- Clayton Received on Fri May 12 2000 - 00:00:00 CDT