LONG RAW problem in Digital UNIX system using Pro*C 
Author Message
 LONG RAW problem in Digital UNIX system using Pro*C

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;

Quote:
}

// -- 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



Wed, 18 Jun 1902 08:00:00 GMT
 LONG RAW problem in Digital UNIX system using Pro*C

All those concerned,

Well, after much head scratching and hair pulling I have come to the
following scenario.  Using the LongRaw structure as I have defined it,
whenever I execute the SELECT query and then access the Length member to
allocate memory I receive a NULL pointer from both malloc and realloc.  If I
change the declaration of LongRaw to use an "int" instead of "long" for the
Length member then the code executes correctly.

This appears to be an error to me.  Is this a problem with the pre-compiler
(2.2.4.0.0) or is this a problem with the Digital UNIX compiler?  -OR- is
Digital UNIX 64-bit and I need to be using the correct integer type?  If I
remember correctly, the Oracle documentation says that the Length member
should be "long" not "int".

Any advice, insight, {*filter*}?
- Clayton



Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. ** Problems with Raw devices while installing ASE on Digital Unix **

2. 24521-PA-South Central-UNIX-ORACLE-DIGITAL-PARAL-SYSADMIN-SERVER-Unix Systems Administrator

3. 24521-PA-South Central-UNIX-ORACLE-DIGITAL-PARAL-SYSADMIN-SERVER-Unix Systems Administrator

4. LONG RAW to LONG RAW

5. Installing Sybase on Digital-Unix (osf1) - defining Raw-Device

6. Informix 7.1 on Digital UNIX - raw or cooked?

7. problem using long raw in trigger

8. problem using long raw in trigger

9. Oracle Thin JDBC Driver: problems streaming long/long raw in parameters


 
Powered by phpBB® Forum Software