Comment 3 for bug 1438775

This seems to be a case of memory corruption, which happens right after SQL_EXEC_Fetch() is called. There are a couple of things that seems to trigger this.

1. Executing a query like below where the query_text column is the last in the select list.
select EXEC_START_UTC_TS,QUERY_ID,USER_NAME,QUERY_TEXT from TRAFODION."_REPOS_".METRIC_QUERY_TABLE;

AND

2. The number of rows in the table is greater than or equal to 100.

The corruption occurs along the fetch buffer that is passed to SQL via WSQL_EXEC_SetDescItem() with desc type of SQLDESC_ROWWISE_ROWSET_PTR. The first byte right after the fetch buffer ends seems to be overwritten with a null character. If that particular byte happens to be already allocated and in use then it would cause a core. Below is an output from a gdb session.

(gdb) p pSrvrStmt->outputDescVarBuffer[(pSrvrStmt->maxRowCnt*pSrvrStmt->outputDescVarBufferLen)+1]
$81 = 28 '\034'

6157 retcode = WSQL_EXEC_Fetch(pStmt, pDesc, 0);
(gdb)
[New Thread 0x7fffd1ae5700 (LWP 25017)]
6158 if (retcode < SQL_SUCCESS)

(gdb) p pSrvrStmt->outputDescVarBuffer[(pSrvrStmt->maxRowCnt*pSrvrStmt->outputDescVarBufferLen)+1]
$82 = 0 '\000'

The pSrvrStmt->outputDescVarBuffer is allocated for pSrvrStmt->maxRowCnt*pSrvrStmt->outputDescVarBufferLen.

As can be seen above the byte right after where the buffer ends had a valid value '\034' before the call to fetch and after the call that byte is overwritten by a null character.

Note, this issue does not occur if the query_text column is not the last in the select list even though the table may have > 100 rows.

Since the memory corruption is happening in the CLI call assigning this bug the SQL executor group.