- I called this intermittent because it doesn’t happen all the time. Today, however, it happened five times. Not good for the production system users. Server is R8.5FP1 on windows server 2003 R2 SP2.
Here’s the “FATAL THREAD” bit of the NSD:
############################################################
FATAL THREAD 8/14 [ nAMgr: 1180: 1584]
FP=0x1accfc54, PC=0x600074a2, SP=0x1accfc38
stkbase=1acd0000, total stksize=32768, used stksize=968
EAX=0x1accfc4c, EBX=0x00000000, ECX=0x00000000, EDX=0x00000004
ESI=0x00000000, EDI=0x13ef3d6e, CS=0x0000001b, SS=0x00000023
DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010246
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x600074a2 nnotes.OSLocalAllocNZ@8+50 (108,1accfca8)
@[ 2] 0x601866c1 nnotes.OSLocalAlloc@8+17 (108,1accfca8)
@[ 3] 0x600c47d2 nnotes.SECRandomNoSem@12+386 (0,0,1accfcbc)
@[ 4] 0x60034c67 nnotes.GetNSFT@4+71 (0)
@[ 5] 0x608605e5 nnotes.NSFHealthCheck@8+21 (5,4)
@[ 6] 0x60019d02 nnotes.NSFNoteClose@4+98 (35)
@[ 7] 0x61cc5a66 nlsxbe.ANNote::~ANNote+230 (0)
@[ 8] 0x61cc55eb nlsxbe.ANNote::`scalar deleting destructor’+11 (1)
@[ 9] 0x61d49ec4 nlsxbe.Java_lotus_domino_local_NotesBase_RecycleObject@12+292 (197bc200,1991fda0,1991fd9c)
############################################################
PASS 2 : FATAL THREAD with STACK FRAMES 8/14 [ nAMgr: 1180: 1584]
FP=1accfc54, PC=600074a2, SP=1accfc38
stkbase=1acd0000, total stksize=32768, used stksize=968
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
Disassembly of c. 10 instructions before and after faulting address 600074a2:
6000747c c745f80c000000 mov dword ptr [ebp+0xf8],0xc ss:1ca2a79a=6543206c
60007483 e858ffffff call 600073e0
60007488 8945e8 mov [ebp+0xe8],eax ss:1ca2a79a=6543206c
6000748b c745e400000000 mov dword ptr [ebp+0xe4],0x0 ss:1ca2a79a=6543206c
60007492 6a00 push 0x0
60007494 6a04 push 0x4
60007496 8d4df4 lea ecx,[ebp+0xf4] ss:1ca2a79a=6543206c
60007499 51 push ecx
6000749a e851a1ffff call 600015f0
6000749f 8b55e8 mov edx,[ebp+0xe8] ss:1ca2a79a=6543206c
FAULT ->600074a2 833a00 cmp dword ptr [edx],0x0 ds:00000004=???
600074a5 751e jnz 600074c5
600074a7 8b45e8 mov eax,[ebp+0xe8] ss:1ca2a79a=6543206c
600074aa 50 push eax
600074ab e8b0eb1700 call 60186060
600074b0 668945ec mov [ebp+0xec],ax ss:1ca2a79b=4320
600074b4 0fb74dec movzx ecx,word ptr [ebp+0xec] ss:1ca2a79b=4320
600074b8 85c9 test ecx,ecx
600074ba 7409 jz 600074c5
600074bc 668b45ec mov ax,[ebp+0xec] ss:1ca2a79b=4320
600074c0 e944010000 jmp 60007609
600074c5 ba7eff0000 mov edx,0xff7e
-
Naturally the entire thing can be produced on-demand. Sorta like Netflix.
-
The crashing application is a Java-based system-to-system interface written for R5 and migrated along to various newer versions, though we skipped R7. Java code is all Designer-based, there are no external JARs involved. It was pretty darned reliable until we put it on R8.5, then the troubles started.
-
I’ve tossed a ton of JVM and overall memory debugging bits into the server’s notes.ini, hoping to capture something wonky there.
Any thoughts? Thanks for your time…