About Duffbert...

Duffbert's Random Musings is a blog where I talk about whatever happens to be running through my head at any given moment... I'm Thomas Duff, and you can find out more about me here...

Email Me!

Search This Site!

Custom Search

I'm published!

Co-author of the book IBM Lotus Sametime 8 Essentials: A User's Guide
SametimeBookCoverImage.jpg

Purchase on Amazon

Co-author of the book IBM Sametime 8.5.2 Administration Guide
SametimeAdminBookCoverImage.jpg

Purchase on Amazon

MiscLinks

Visitor Count...



View My Stats

« Attack Squirrel Of Death! | Main| Memo to phishers... »

How to Check for Memory Leaks in a LotusScript Agent

Category Software Development

I ran across this gem in the KnowledgeBase today...  you may never need it, but if you do it could be a lifesaver...

------------------

How to Check for Memory Leaks in a LotusScript Agent

Document Number:  1109686

Problem

How can you determine whether a LotusScript agent is leaking memory?


Content
** Note**:        This technote should be distributed on an as-needed basis only - specifically, only when either you or a customer suspects that there are memory leaks in a LotusScript agent.  The agents included below are intended to be used only to identify memory leaks in a LotusScript agent.

If you suspect that a LotusScript agent is leaking memory, use one of the following scripts to determine whether memory is indeed not being freed once the agent finishes executing.

The following scripts monitor allocated memory for each thread.  Each executive process takes up one thread.  You need to be aware of this as you are troubleshooting - because the values may change when a different executive process runs your agent than the last time it was run.  When more than one executive process is being run on the sever, there is no way to control which thread the memory check agent will run on.  If it runs on a thread other than the thread that the leaking agent ran on, then the output is irreverent.  When possible, it may be best to limit the number of executive processes (set in the Server document) to 1 while troubleshooting the leak.

Each memory-checking script should be placed in an agent to execute before the agent in question and again after the agent in question.  Compare the two sets of numbers.  If the second set of numbers is higher, all memory has not been freed.

If a memory leak is found, isolate the pieces of the code that are leaking.  One way to do this is to break up the code into smaller pieces.  Execute the appropriate leak-checking agent, then execute the modified agent, then execute the leak-checking agent again.

Leak-Checking Agents:

I.  If the agent is running in the fore-ground, use the following code:

Sub Initialize  
    Msgbox(" Total LotusScript Memory Allocated: " + (Lsi_info(50)))
    Msgbox(" Total LotusScript Memory Allocated from OS: " + (Lsi_info(51)))
    Msgbox(" Total LotusScript Blocks Used: " + (Lsi_info(52)))    
End Sub

This agent displays a message box showing the amount of memory allocated via LotusScript.  Remember to run this code immediately before and after you execute the agent in question - to compare values and determine whether the agent is indeed leaking memory.

II. If the agent is scheduled, use the following code:

Sub Initialize  
     Print "Total LotusScript Memory Allocated: " + Str$(Lsi_info(50)) + Chr$(10) + Chr$(13)
    Print "Total LotusScript Memory Allocated from OS: " + Str$(Lsi_info(51)) + Chr$(10) + Chr$(13)
    Print "Total LotusScript Blocks Used: " + Str$(Lsi_info(52)) + Chr$(10) + Chr$(13)

End Sub

This agent writes to the server's LOG.NSF file.  Remember to run this code immediately before and after the agent in question - to compare values and determine whether the agent is indeed leaking memory.

Comments

Gravatar Image1 - lsi_info(9) = Current language (en for english)

Gravatar Image2 - So, is that some kind of hidden constant array? Or are we missing a declaration? Tried it yet? (sorry for all the questions - that's what usually happens to me when I see something potentially really cool).

Gravatar Image3 - Hi,
i recommend using the LScript Function "getThreadInfo()" which is supported by Lotus.

But there are no mem-Params - at least none documented.

Gravatar Image4 - It must be... yes, I ran it exactly as is, and it worked perfectly.

Gravatar Image5 - I have only found the common ones referenced in a lot of blog entries if you hit Google. I found the following by John Head in Rocky's blog, for those who are interested...
Comment posted by John Head10/31/2003 10:14:32 AM
While working with Rocky in 1999 as a consultant for the company he was at, and working at that company with him in 2000, I picked up many of these functions. But since 6 was released, there is a new 'undocumented' function lsi_info in my error handler stuff. the following can be done with the funciton:

lsi_info(1) = current line number
lsi_info(2) = current sub/function name
lsi_info(3) = current module
lsi_info(6) = lotusscript version
lsi_info(12) = name of lotuscript function that called this one, to build stack traces
lsi_info(50) = lotusscript memory allocated
lsi_info(51) = lotusscript memory allocated from os
lsi_info(52) = lotusscript blocks used

Its great for getting as much info from the code when the error happens as possible

Gravatar Image6 - There are a few LSI parms for threads in the lsprcval.lss file...

'-----------------------------------------------------------------------------
' File: lsprcval.lss
' Copyright (c) 1997 Lotus Development Corporation
'
' Description: Constants for use with the LSITHREADINFO builtin
'
'-----------------------------------------------------------------------------
public const LSI_THREAD_LINE=0
public const LSI_THREAD_PROC=1
public const LSI_THREAD_MODULE=2
public const LSI_THREAD_VERSION=3
public const LSI_THREAD_LANGUAGE=4
public const LSI_THREAD_COUNTRY=5
public const LSI_THREAD_TICKS=6
public const LSI_THREAD_TICKS_PER_SEC=7
public const LSI_THREAD_PROCESS_ID=8
public const LSI_THREAD_TASK_ID=9

Gravatar Image7 - Tom, know of any resource to get *all* the LSI_INFO details? The stuff in arrays 1-12 is pretty interesting too. If they go all the way to 52, there must be some neat things in between.

Gravatar Image8 - Hi, thanks for the tip. What we should expect when the results bring a negative number? As example:

Agent (at start point):
Total LotusScript Memory Allocated: 15744120
Total LotusScript Memory Allocated from OS: 18839068
Total LotusScript Blocks Used: 25272

Agent (at end point)
Total LotusScript Memory Allocated: 15839992
Total LotusScript Memory Allocated from OS: 18880028
Total LotusScript Blocks Used: 25553

Gravatar Image9 - Sorry, my bad, the last post didn't bring one negative on the example, but I already had one before. In such a case what to do? Where should we expect zero values summing up the differences, on the first, second or third line? Thanks in advance.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Want to support this blog or just say thanks?

When you shop Amazon, start your shopping experience here.

When you do that, all your purchases during that session earn me an affiliate commission via the Amazon Affiliate program. You don't have to buy the book I linked you to (although I wouldn't complain!). Simply use that as your starting point.

Thanks!

Thomas "Duffbert" Duff

Ads of Relevance...