IC65616: MEMORY LEAK WITH AN ESQL PROGRAM ON 11.5 WHICH DOESN'T REPRODUCE ON 9.4

APAR status

• Closed as program error.

Error description

• We use a simple esqlc program which uses a nested loop with a
  prepared cursor in the inner loop.  The database server is
  allocating more and more memory in the same session even though
  the cursor is closed before leaving each iner loop.  With every
  run of the outer loop the amount of memory increases.
  
  To see the increase of memory consumption you need to run the
  onstat -g ses repeatedly, it should look very similar to the
  below:
  
  51 informix 9 589840 portland 1 200704 180400 off
  51 informix 9 589840 portland 1 200704 180400 off
  51 informix 9 589840 portland 1 200704 180400 off
  51 informix 9 589840 portland 1 212992 207688 off
  51 informix 9 589840 portland 1 233472 214192 off
  51 informix 9 589840 portland 1 233472 214192 off
  51 informix 9 589840 portland 1 233472 230248 off
  51 informix 9 589840 portland 1 258048 253800 off
  51 informix 9 589840 portland 1 266240 248016 off
  51 informix 9 589840 portland 1 290816 285544 off
  51 informix 9 589840 portland 1 303104 298688 off
  51 informix 9 589840 portland 1 327680 323264 off
  51 informix 9 589840 portland 1 348160 345792 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 368640 349392 off
  51 informix 9 589840 portland 1 389120 386752 off
  51 informix 9 589840 portland 1 401408 383184 off
  51 informix 9 589840 portland 1 401408 383184 off
  51 informix 9 589840 portland 1 401408 383184 off
  51 informix 9 589840 portland 1 401408 383184 off
  51 informix 9 589840 portland 1 401408 383184 off
  
  
  Results:
  
  9.40.FC5 - Shows no memory leak
  9.40.FC5W1 - shows memory leak
  9.40.FC5W2 - shows memory leak
  11.50.UC4 - shows memory leak
  
  Comparison between the SQLIDEBUG from both 9.40.FC5 and
  9.40.FC5W1 and both show basically the same communication
  between the server and the client.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Users who use cursor to fetch data from a prepared query     *
  * which has decimal column and constant integer comparison in  *
  * the predicate                                                *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * User will see memory leaks when fetching data from a         *
  * prepared query which has a predicate with decimal column and *
  * constant integer comparison. The leaked memory will be freed *
  * once the prepared statement is freed or the session is       *
  * closed.  Memory used for integer to decimal conversion each  *
  * time is allocated from sd heap and those memories do not get *
  * freed until the statement ends.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Upgrade to 11.50.xC7 and above.                              *
  ****************************************************************
  

Problem conclusion

• Instead of allocating memory from sd heap, a local buffer with
  size of 32+1 is used for the integer to decimal conversion. In
  case if decimal length is larger than 32+1, memory from SQSCB
  pool will be used and will be explicitly freed immediately once
  conversion is completed.
  Problem first fixed in 11.50.xC7
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  IBM IDS ENTRP E

• Fixed component ID

  5724L2304

Applicable component levels

• RB15 PSN

     UP