DB2 FOR LUW / DB2FORLUW / A50 - DB2

MON_GET_PAGE_ACCESS_INFO() can end up with SEGV (crash/abort) or 
eventually memory corruption 
if it retrieves rows for both the local and some remote nodes. 
The problem is that when both types 
of rows are retrieved we pack them in a new buffer that fits 
exactly the number of rows retrieved. 
Later on when we fetch rows from that buffer we use a loop that 
allows to access rows[number of rows] 
when indeed rows[number of rows - 1] should be the last one. 
 
The segv would occur in the rare case where the buffer end 
happens to also be the end of a region. 
Else, if the memory located after contains certain value we 
might end up with a copy (table name) 
that would corrupt the memory placed after the buffer. 
 
Here is a more detailed description. 
 
== step 1 == 
 
  In sqlrwGetWLMTableFunctionMergedResult() we retrieve the 
  rows we are interested in. We will retrieve both 'local' node 
  and 'remote' nodes rows. This is done as this: 
 
  sqlrwGetWLMTableFunctionResult() 
    -- retrieve local rows and store them in a buffer allocated 
    -- to handle SQLRW_EXPANDABLE_BUFFER_DEFAULT_SIZE (10) rows. 
 
  sqlrwSendGetWLMTableFunctionResult() 
    -- retrieve rows from other nodes and store them in a buffer 
       that fits the size of candidate rows. 
 
  If we have BOTH local and remote rows we will merge all rows 
  in a single buffer allocated with the length of local + remote 
  rows. NOTE that in our case this buffer will host 4 rows which 
  is SMALLER than the regular case when fetching only local 
rows. 
 
== step 2 == 
 
  In monGetPageAccessInfo() we will now process the rows we 
retrieved. 
  The steps are open, fetch, close: 
 
  case SQLUDF_TF_OPEN: 
    save_area->pBuffer = NULL; 
    save_area->currentRowNo = 0; 
 
  case SQLUDF_TF_FETCH: 
    while ( save_area->rowCount > 0  && 
            save_area->currentRowNo <= save_area->rowCount ) 
 
    -- if we retrieve 4 rows, save_area->rowCount will be 4 
    -- currentRowNo is initialized to 0 but we allow it to go 
    -- to 4 which is above the last row... (row[4] = 5th row) 
    -- it will work fine if we have only 'local' 
    -- rows as the default buffer size fits 10 rows via 
    -- SQLRW_EXPANDABLE_BUFFER_DEFAULT_SIZE 
    -- but if we have both local and remote (our case) 
    -- we allocate a common buffer for both with a size.

**************************************************************** 
* USERS AFFECTED:                                              * 
* all platform                                                 * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to 10.5.0.3                                           * 
****************************************************************

DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
 

Problem Fixed In 10.5.0.3

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

27.08.2013
06.05.2014
06.05.2014