LO51102: HTTP CRASH ON LOCKMEMHANDLE

APAR status

• Closed as fixed if next.

Error description

• Then server crashes on the http task.
  The following error was reported in the logs: PANIC:
  LookupHandle: handle out
  of range
  The crash stack was
  ############################################################
  ### thread 26/109: [   nHTTP:  0c10:  0270] FATAL THREAD
  (Panic)
  ### FP=0x0f73e150, PC=0x7c82860c, SP=0x0f73e0e0
  ### stkbase=0x0f740000, total stksize=262144, used
  stksize=7968
  ### EAX=0x00000000, EBX=0x00000000, ECX=0x0019060c,
  EDX=0x00190608
  ### ESI=0x00000df4, EDI=0x00000000, CS=0x0000001b,
  SS=0x00000023
  ### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000
  Flags=0x00000293
  ############################################################
   [ 1] 0x7c82860c ntdll.KiFastSystemCallRet+0
  (df4,927c0,0,f73e6d8)
   [ 2] 0x77e61c8d kernel32.WaitForSingleObject+18
  (df4,927c0,1,f73e8f4)
  @[ 3] 0x601a8ef4 nnotes.OSRunExternalScript@8+1300 (258,1)
  @[ 4] 0x601a938a nnotes.FRTerminateWindowsResources+986
  (1,0,1010,1)
  @[ 5] 0x601a974f nnotes.OSFaultCleanupExt@24+895
  (1444dd8,1010,0,0,0,f73ec24)
  @[ 6] 0x601a97da nnotes.OSFaultCleanup@12+26 (0,1010,0)
  @[ 7] 0x601b4cd4 nnotes.OSNTUnhandledExceptionFilter@4+276
  (f73fc5c)
  @[ 8] 0x60179d78 nnotes.Panic@4+520 (60bbfb17)
  @[ 9] 0x60002c95 nnotes.LockMemHandle@12+37 (10411a,f73fc98,0)
  @[10] 0x60002dd4 nnotes.OSMemoryUnlock@4+20 (10411a)
  @[11] 0x10032317 nhttpstack.HTMemDeallocObject+55
  (45839e34,100191d9,45839e34,7ea9fdc)
  @[12] 0x1001c2b6 nhttpstack.DeallocObject+6 (1,0,27554578,1)
  @[13] 0x100192c9 nhttpstack.HTMemoryPool::Reset+57
  (0,f4c0bd9,0,746f4c2f)
  @[14] 0x100261a1 nhttpstack.HTSession::StartRequest+1041
  (f4c0be5,f4c0bd9,0,5c4)
  @[15] 0x1002da3f nhttpstack.HTWorkerThread::CheckForWork+399
  (0,f4c0bd9,3,1002a5aa)
  @[16] 0x1002df88 nhttpstack.HTWorkerThread::ThreadMain+88
  (f4c0bd9,0,0,0)
  @[17] 0x6010490d nnotes.ThreadWrapper@4+173 (0)
   [18] 0x77e6482f kernel32.GetModuleHandleA+223 (0,0,0,0)
  
  This looks like the same defect as reported in HSAO837UDR but
  for 8.0.2
  

Local fix

Problem summary

• This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# GTON84SFML.
  If this issue occurs in a future 8.5.3 or above release, it may
   be raised for investigation there.
  

APAR Information

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

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

Fix information

Applicable component levels

• R802 PSN

     UP