IBM IDS ENTRP E / 5724L2304 / B15 - IDS 11.50

The defect is found while running MASS-C4  stress test . 
While running the connlock test , I saw as assert failure .  I 
noticed this assert failure after killing the server. 
Attaching the  af file too .  I will attempt the connlock test 
again to check if I can reproduce the problem . 
from online.log 
-------------------------- 
21:26:11  TESTMODE:long key buffers on VP:7 number key 
buffers:5 
21:26:11  TESTMODE:keybuffs alloc attempts for VP:7: long:2194 
cached:2188, short 
:460915168 cached:460914968 
21:26:11  TESTMODE:short key buffers on VP:7 number key 
buffers:9 
21:29:06  SCHAPI: NEXT EXECUTION  2008-03-28 01:29:05 TASK 
mon_vps:6 
21:29:06  SCHAPI: NEXT EXECUTION  2008-03-27 23:29:05 TASK 
mon_memory_system:8 
21:29:06  SCHAPI: NEXT EXECUTION  2008-03-27 22:29:05 TASK 
mon_checkpoint:7 
21:29:06  SCHAPI: NEXT EXECUTION  2008-03-28 01:29:05 TASK 
mon_profile:5 
21:29:07  Assert Failed: Exception Caught. Type: MT_EX_OS, 
Context: mem 
21:29:07  IBM Informix Dynamic Server Version 11.50.UC1 
21:29:07   Who: Session(23, informix@, 0, 5abc1600) 
  Thread(70, dbWorker2, 5ab96dd8, 3) 
  File: mtex.c Line: 406 
21:29:07   Action: Please notify IBM Informix Technical 
Support. 
21:29:07   See Also: /tmp/af.42e57f2 
21:29:31  Invoking debugger on oninit: VP (PID/ThreadID) = 
20764 
21:29:31 
  Thread(70, dbWorker2, 0x0, 3) 
21:29:31  oninit pid 20764 waiting for debugger 
21:34:17  TESTMODE:long key buffers on VP:1 number key 
buffers:5 
21:34:17  TESTMODE:keybuffs alloc attempts for VP:1: long:3724 
cached:3718, short 
:468391886 cached:468391650 
21:34:17  TESTMODE:short key buffers on VP:1 number key 
buffers:6 
Checked  with Mirav and this is what he gathered from the af 
files and message log. 
Mirav C. Kapadia ok 
? ok... This is what I can tell as of now. 
? The mt_thread_state_detailed() function was introduced 
on 15-Feb-08 for 152796 by Karl Ostner. 
? That would be BAR team which is responsible for this 
change. I believe dbcron has not much to do with this because 
we are trying to execute a SQL statement which is crashing in 
mt_thread_state_detailed() 
? It might be as simple as to put some more "null" 
checks in this function. I would suggest trying to reproduce 
this in the background and sending this AF stack to Karl Ostner 
with my comments and stack you got. 
? This should be a recent regression. Let me know if you 
agree to this. 
From Karl 
------------------ 
Anju, 
I agree with Mirav that some more checking for null pointers 
can reduce the likelihood of the problem. 
It would help to see the relevant thread's TCB structure. 
If you can reproduce the problem, please leave the oninit 
process waiting for debugger, 
so that you (or so. else) can find out which pointer was null. 
Check for tcb->state, and 
depending on the state the other pointers accessed in 
mt_thread_state_detailed(). 
If the problem appears to reproduce some more times, it may be 
necessary to lock 
the TCB structure while accessing the pointers, but I want to 
avoid this unless its 
really necessary. 
Thanks, 
  Karl

**************************************************************** 
* USERS AFFECTED:                                              * 
* IDS users accessing sysmaster:systcblst                      * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Informix Dynamic Server aborted when accessing               * 
* sysmaster:systcblst                                          * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* upgrade to IDS 11.50.xC2 or higher                           * 
****************************************************************

problem fixed in 11.50.xC2

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

21.12.2008
17.06.2009
17.06.2009

11.50.xC2