DB2 - Problembeschreibung
Problem IC95270 | Status: Geschlossen |
MON_GET_PAGE_ACCESS_INFO() CAN END UP WITH SEGV (CRASH/ABORT) OR EVENTUALLY MEMORY CORRUPTION | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problembeschreibung: | |
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. | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * all platform * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Update to 10.5.0.3 * **************************************************************** | |
Local-Fix: | |
verfügbare FixPacks: | |
DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows | |
Lösung | |
Problem Fixed In 10.5.0.3 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 27.08.2013 06.05.2014 06.05.2014 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.5.0.3 | |
10.5.0.3 |