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:                                              * 
* Users running db2 v10.5 before Fix Pack 3                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade do DB2 version 10.1 Fix Pack 3 or above.             * 
****************************************************************

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
 

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

27.08.2013
22.09.2014
22.09.2014