DDE R8.5.1FP1 crashed during cut operation

HCL Domino Domino Forum
1

############################################################### thread 7/22: [ NLNOTES: 0ac0: 0f40] FATAL THREAD (Panic)

FP=0x03e8dbb4, PC=0x7c90e526, SP=0x03e8db50

stkbase=0x03e90000, total stksize=262144, used stksize=9392

EAX=0x00000000, EBX=0x03e8e784, ECX=0x00000015, EDX=0x00000000

ESI=0x00000498, EDI=0x00000000, CS=0x0000001b, SS=0x00000023

DS=0x00000023, ES=0x00000023, FS=0x00000038, GS=0x00000000 Flags=0x00000297

############################################################

[ 1] 0x7c90e526 ntdll.KiIntSystemCall+6 (498,493e0,0,3e8e364)

[ 2] 0x7c802542 kernel32.WaitForSingleObject+18 (498,493e0,3e8eaf8,3e8e7a3)

@[ 3] 0x601b4f65 nnotes.FRSendCommandToService+789 (3e8e384,3e8e784,3e8e7a3,0)

@[ 4] 0x601b5b9f nnotes.OSRunExternalScript@8+1055 (12c,1)

@[ 5] 0x601b611f nnotes.FRTerminateWindowsResources+975 (1,1010,1,0)

@[ 6] 0x601b6548 nnotes.OSFaultCleanupExt@24+984 (ce6a68,1010,0,0,0,3e8ee20)

@[ 7] 0x601b65ca nnotes.OSFaultCleanup@12+26 (0,1010,0)

@[ 8] 0x601c1b74 nnotes.OSNTUnhandledExceptionFilter@4+276 (3e8fe58)

@[ 9] 0x601847dd nnotes.Panic@4+589 (3e8fe70)

@[10] 0x60184894 nnotes.OSWCTPanicShutdown+84 (b10,13a2ee8,13a57ee,3)

@[11] 0x636811a3 nnotesws.WCTShutdownThread+211 (b10,138390,7c910041,0)

@[12] 0x6010dadf nnotes.ThreadWrapper@4+175 (0)

[13] 0x7c80b729 kernel32.GetModuleFileNameA+442 (0,0,0,0)

…[lots of stack frames omitted]…

@[ 9] 0x601847dd nnotes.Panic@4+589 (3e8fe70)

   Parameter 1:

        03e8fe70 50726F63 65737320 6E6F7465 73322E65 | Proc ess  note s2.e |

        03e8fe80 78652028 7069643D 32383332 29206E6F | xe ( pid= 2832 ) no |

        03e8fe90 206C6F6E 67657220 65786973 74732E20 |  lon ger  exis ts.  |

        03e8fea0 41204A56 4D206661 756C7420 636F756C | A JV M fa ult  coul |

        03e8feb0 64206265 20726573 706F6E73 69626C65 | d be  res pons ible |

        03e8fec0 2E20506C 65617365 20696E73 70656374 | . Pl ease  ins pect |

        03e8fed0 20746865 20776F72 6B737061 63655C6C |  the  wor kspa ce\l |

        03e8fee0 6F677320 64697265 63746F72 7920666F | ogs  dire ctor y fo |

        03e8fef0 72206A61 76612C20 68656170 2C206F72 | r ja va,  heap , or |

        03e8ff00 20737973 74656D20 636F7265 2066696C |  sys tem  core  fil |

        03e8ff10 65732E00 00000000 94010000 00000000 | es.. .... .... .... |

        03e8ff20 94010000 C00A0000 00000000 01000000 | .... .... .... .... |

  • I renamed a custom control so I could recreate it. Upon recreating it with the same name (using “New” on the context menu for Custom Controls), the “new” control contained the same code as the renamed one, instead of being blank as expected. Deleted the “new” control and recreated it with the same name. Same result. Attempted to cut the original, renamed control. DDE froze for about three minutes with pegged CPU, so I loaded Task Manager to see what was taking all the resources. Usage dropped significantly, then about a minute later DDE vanished and NSD ran.

  • This instance is running on a VM with nothing installed but:

HP Printer drivers

Network shared printer driver

Cisco VPN Client (not currently active)

VirtualBox Guest extensions

Firefox 3.5.8

R8.5.1FP1 Standard originally clean installed on a new VM instance. Only Firefox has gone in after it.

  • There are numerous javacore and heapdump files in the workspace/logs directory, and one core file. It looks like every one of them was generated between the time DDE froze up and the time NSD ran, totalling 10 files in all.

Hope this helps…

EDIT:

  • The latest javacore file has this line in the “SHARED CLASSES subcomponent dump routine” section just after the Cache Summary:

2SCLTEXTCPF Cache is 100% full

That doesn’t look good. Just below that under “Cache Memory Status” it appears to indicate that cache is a memory-mapped file named “xpdplat_.jvm” and it gives a path to that on the hard drive. The hard drive is not full, and the VM had about 200MBytes of RAM at the time of the crash, or at least that’s what Task Manager reported, so that certainly isn’t necessarily accurate.

  • So did I just run out of memory as the full cache implies, or did something else go wrong? If I did run out of memory should I bump the JVM’s allocation for DDE or assign more memory to the VM? If I should bump DDE’s JVM, how does one do that?

  • This post → seems to indicate that notes2.exe disappearing isn’t memory-related at all, but I need to delete the workspace directory. Seems like a lot of stuff under there I may have to re-create. Guess I’ll rename it and see what happens.

Thanks for your time…

2

Subject: there were some fixes in this area in 8.5.2

custom control renaming, that is.

Will try to reproduce your scenario, but I am at least hopeful that it has already been resolved in 8.5.2.

3

Subject: I doubt it’s reproducable…

  • This is the first time I remember DDE crashing for this particular thing, but I do remember other DDE crashes having the same “problem” … that NSD showed notes2.exe had gone AWOL. That presumed lack of reproducibility is why I put all that debug stuff there, so it might tell someone in the know more about what’s happened. (shrug) There it is.

  • I haven’t put in *.2 yet. After the nightmare introduced by going from R8.5 to R8.5.1 (mainly the entire XPage event handling system was changed, destroying backward compatibility and costing days of time) I’m not feeling as anxious to “move up”. I can’t afford days of down time right now.

Thanks for your time…

4

Subject: The underlying issue happened again today…

  • That underlying issue (prior to the crash) would be that deleting a custom control and creating it again using “New Custom Control” (with the same name) makes the OLD custom control re-appear. If I close DDE and re-launch it this does not happen.

  • I once again beg someone at Lotus to tell me how to delete all of DDE’s caches so I don’t have to close DDE and lose where I am in fifteen editor tabs.

Thanks for your time…

5

Subject: not reproducible in the next point release (8.5.2)

and I will find an 8.5.1 build to be sure I can reproduce it there, to be sure it’s fixed.

But I just deleted a custom control, recreated it with the same name, and all was as expected.

No crash, no old code showing up, all is well.

It is not a caching issue you are seeing so much as an incomplete delete/rename, is my suspicion. Please examine the nsf in the Eclipse navigator after a delete to see what is still around. Look in the Local\xsp folder, as well as the CustomControl folder. We did fix some things in this neighborhood, and my test just confirmed my suspicions.

The nsd snippets were not very telling - they just indicate a panic on shutdown, they are no help. Perhaps the javacores will have more info. Please send them along with the full nsd to mleland at us.ibm.com.