Informix - Problem description
Problem IT15386 | Status: Closed |
ASSERT FAILED: YIELD_PROCESSOR: CONDITIONAL LATCH COUNT NON-ZERO WHEN LOCK TABLE DYNAMICALLY GROWS AND ALRM_ALL_EVENTS SET TO 1 | |
product: | |
INFORMIX SERVER / 5725A3900 / C10 - IDS 12.10 | |
Problem description: | |
This problem only happens on Windows. The above assertion will be seen if the number of cpus configured is set to 1. If the server has > 1 cpu vp, then a server hang can be the result as the owner of a spin lock will yield, allowing other threads to run, and if the other threads that run attempt to grab the spin lock, the owner of the spin lock will not be able to run to release it (because all the threads attempting to acquire the spin lock do not give up the cpu vp). The stack trace in the af file is this (as in theory multiple database actions could cause the lock table to grow, the only relevant portion of the stack is the frames above lkmanagex) (oninit)afhandler (oninit)afcrash_interface (oninit)yield_processor_svp (oninit)mt_yield (oninit)mt_system (oninit)invoke_alarmf (oninit)mt_sysmsg_body (oninit)lkgrow (oninit)lkalloc (oninit)lkmanagex (oninit)lkrow (oninit)allocslot (oninit)alloc_lastpage (oninit)allocvrow (oninit)wrt_home (oninit)wrtrecord (oninit)rswrite (oninit)fmwrite (oninit)aud_sqiswrite (oninit)chkrowcons (oninit)addone (oninit)ins1row (oninit)insone_next (oninit)doinsert (oninit)sq_putinsert (oninit)sqmain With multiple cpu vps and a server hang, what would be seen is a non-running thread (would likely be in a ready state) with a stack like this: Stack for thread: 51 sqlexec base: 0x0000000084868000 len: 167936 pc: 0x0000000140e06b1f tos: 0x000000008488d6e0 state: ready vp: 8 NT_yield_processor_mvp () mt_yield () mt_system () invoke_alarmf () mt_sysmsg_body () lkgrow () lkalloc () lkmanagex () lkitem () btnexlock () btadditem () rsbtadditem () isbtadditem () fm_idxinsert () fmwrite (2, 845ddb80, 848a4b00, 840f5d74) aud_sqiswrite () chkrowcons () addone () ins1row () insone_next () doinsert () sq_putinsert () sqmain () And then 1 or more threads running on other cpu vps that are then spinning on spin lock call from lkalloc like this (these stacks since the threads are running has to be captured with the onmode -X s command) 14:48:54 Stack for thread: 48 dbScheduler base: 0x000000008443f000 len: 135168 pc: 0x0000000140e40318 tos: 0x000000008445ce40 state: running vp: 8 (oninit)afstack_dump (oninit)notifyvp_signal_handler (oninit)mt_nap (oninit)mt_spin_lock_wait (oninit)mt_fast_lock (oninit)lkalloc (oninit)lkmanagex (oninit)lktable (oninit)lkrow (oninit)gather_records (oninit)rsread (oninit)fmread (oninit)readidx_old (oninit)gettupl (oninit)scan_next (oninit)dodelupd (oninit)excommand (oninit)sq_execute (oninit)mi_exec_prepared_statement (oninit)ph_task_lock (oninit)ph_get_next_task (oninit)db_sched (oninit)udrlm_clang_execute_internal (oninit)udrlm_clang_execute (oninit)udrlm_exec_routine (oninit)udr_execute (oninit)dbsched_start_udr (oninit)th_init_initgls (oninit)startup | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * Windows users with ALRM_ALL_EVENTS enabled. * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to IDS 12.10.FC7 when available. * **************************************************************** | |
Local Fix: | |
Solution | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 20.05.2016 29.06.2016 29.06.2016 |
Problem solved at the following versions (IBM BugInfos) | |
12.10.FC7 | |
Problem solved according to the fixlist(s) of the following version(s) |