2190021 - ES (Extended Segment Memory) Lock Implementation

The work process initialization was blocked with status 'WP_NEW' because of ES (Extended Segment Memory) lock. The affected instance was finally standstill and not able to process new incoming requests within time as all work processes are hanging with the issue.

In DPMON/SM66 snapshot, the semaphore 10 and 33 wait were observed.

Workprocess Table
=================

No Type  Pid    Status  Cause Start Rstr  Err Time Cl  SemR SemL
--------------------------------------------------------------------
 0 DIA    28120 New           yes   no     9 16727  100 10
 1 DIA     1892 New           yes   no     4 14610  100 10
 2 DIA    24859 New           yes   no     7 16517  100 10
 3 DIA     2314 New           yes   no     7 17139  100 10
 4 DIA    24860 New           yes   no     2 15892  100 10
 5 DIA    24861 New           yes   no     4 17853  000 10
 6 DIA     2315 New           yes   no     5 17853  100 10
 7 DIA     7602 New           yes   no     6 17630  100 10
 8 DIA    11688 New           yes   no     4 17223  100 10
 9 DIA    12000 New           yes   no     7 17810  100 10
10 DIA    24801 New           yes   no     3 17741  100      10,33
11 DIA    24802 New           yes   no     3 15962  000 10
12 DIA    24803 New           yes   no     2 17473  100 10
13 DIA     7189 New           yes   no     1 15892  100 10
14 DIA    24805 New           yes   no     5 17519  100 10
15 DIA    24862 New           yes   no     4 17802  100 10
16 DIA    24806 New           yes   no     6 17699  100 10
17 DIA    24807 New           yes   no     8 17853  100 10
18 DIA    24808 New           yes   no     9 12743  100 10
19 DIA    24810 New           yes   no    10 17395  100 10
20 DIA    24811 New           yes   no     6 17417  100 10

Note: User and program information columns are removed in above snapshot.

The following call stack was observed on the holder of semaphore 33 work process by sapstack tool (SAP Note 1964673 - C-Call stack analysis) or operating system utility (e.g. gstack in Linux):

sched_yield() + 0x30 (/usr/lib/hpux64/libc.so.1)
Sem2Yield() at sem2xx.c:1332
EsILock() at esxx.c:3946
EsILock() at esxx.c:3810
STD_EsInit() at esxx.c:1536
EsInit() at esxxfunc.c:838
EmInit2() at emxx.c:707
EmInit() at emxx.c:641
ThShMCreate() at thxxhead.c:2917
ThIPCInit() at thxxhead.c:2199
ThInit() at thxxhead.c:1590
ThStart() at thxxhead.c:1139
DpMain() at dpxxdisp.c:1169
main() at thxxanf.c:80
main_opd_entry() + 0x50 (/usr/lib/hpux64/dld.so)

OR (Another example in Windows)

ntdll!NtDelayExecution
KERNELBASE!SleepEx
disp+work!MtxLock_SPIN [mtxxx.c (2581)]
disp+work!EsILock [esxx.c (3422)]
disp+work!STD_EsInit [esxx.c (1592)]
disp+work!EsInit [esxxfunc.c (843)]
disp+work!EmInit2 [emxx.c (722)]
disp+work!EmInit [emxx.c (433)]
disp+work!ThShMCreate [thxxhead.c (2952)]
disp+work!ThIPCInit [thxxhead.c (2215)]
disp+work!ThInit [thxxhead.c (1603)]
disp+work!ThStart [thxxhead.c (1157)]
disp+work!DpMain [dpxxdisp.c (1204)]

NetWeaver ABAP Application Server

EsILock, ES_SPIN_LOCK_ERROR, Semaphore 33, es/lock_method, em/use_sema_lock, mutex, mtx , KBA , BC-CST-MM , Memory Management , Problem