DB2 - Problem description
Problem IC92031 | Status: Closed |
POSSIBLE CRASH (ABORT/SEGV) WHEN RUNNING OUT OF MEMORY BECAUSE OF RECURSION CONSUMING UP THE STACK | |
product: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problem description: | |
The signature here will be that we will end up with segv when trying to allocate a new frame in the stack and the frame address will fall in the range of the guard page. Also, most of the stack will be filled up with functions from oss layer for analysing out of memory error. From the stack example below what should be common is the recursion seen in the last top frames: Frame for _ossMemAlloc() Frame for ossGetPhysSwapInfo() Frame for ossErrorGetMemoryStatistics() Frame for ossErrorAnalysis() returned on call to ossErrorMemoryAnalysis() Frame for ossSystemErrorHandler() Frame for _ossMemAlloc() Frame for ossGetPhysSwapInfo() Frame for ossErrorGetMemoryStatistics() Frame for ossErrorAnalysis() returned on call to ossErrorMemoryAnalysis() Frame for ossSystemErrorHandler() Frame for _ossMemAlloc() Frame for ossGetPhysSwapInfo() Frame for ossErrorGetMemoryStatistics() Frame for ossErrorAnalysis() returned on call to ossErrorMemoryAnalysis() Frame for ossSystemErrorHandler() Frame for _ossMemAlloc() Frame for ossGetPhysSwapInfo() Frame for ossErrorGetMemoryStatistics() Frame for ossErrorAnalysis() returned on call to ossErrorMemoryAnalysis() Frame for ossSystemErrorHandler() Frame for _ossMemAlloc() Frame for sqlnlsMessage() Frame for sqlnlsgmsg() Frame for sqlogmsg_noconv() Frame for pdGetMessage() returned on call to pdLoadMessage() Frame for pdLogInternal() Frame for pdLog() Frame for sqlt_logadmin() Frame for sqlexGetGroupsForUser() Frame for sqlexSlsSystemAccrdb() Frame for sqlexEngAuthenticate() Frame for sqleExecuteSecurityCheck() Frame for sqeApplication::AppLocalStart() Frame for sqlelostWrp() Frame for sqleUCengnInit() Frame for sqleUCagentConnect() Frame for sqljsConnectAttach() Frame for sqljs_ddm_accsec() Frame for sqljsParseConnect() Frame for sqljsParse() Frame for sqljsSqlam() Frame for sqljsDriveRequests() Frame for sqljsDrdaAsInnerDriver() Frame for sqljsDrdaAsDriver() Frame for sqeAgentGRunEDU() Frame for sqlzRunEDU() Frame for sqloEDUEntry() This issue can occur on Solaris due to the fact that function 'ossGetPhysSwapInfo()' on Solaris attempts to allocate memory. And this probably may also happen in other platforms with other situations as in funtion 'ossSystemErrorHandler()' we do not detect that we are entering again for the same reason. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * Systems running DB2 UDB on Solaris machines. * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrading to db2 version v101fp3 resolves this issue. * **************************************************************** | |
Local Fix: | |
available fix packs: | |
DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows | |
Solution | |
First fixed in db2v101fp3. | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 01.05.2013 18.10.2013 18.10.2013 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) | |
10.1.0.3 | |
10.1.0.3 |