1748006 Members
4523 Online
108757 Solutions
New Discussion юеВ

Re: Memory leak

 
Richard W Hunt
Valued Contributor

Re: Memory leak

When I last saw a problem like this on my system (and referencing the Allocate System Memory) function, it was caused by something growing its working set because of a string processing issue.

By any chance are those two programs written in a language for which the string paradigm is that a string is actually a descriptor that points somewhere in the program heap? (As opposed to FORTRAN-like, where strings are pre-allocated and fixed length.)

The problem was "thrashing" the program's scratchpad. You would probably also see a sudden increase in paging/swapping activity just before this problem reared its ugly head.
Sr. Systems Janitor
Hoff
Honored Contributor

Re: Memory leak

Richard is referring to modifications to a dynamic string descriptor; erroneously writing to the descriptor as if it were a static descriptor.

That sequence can certainly result in memory loss, but it's typically a sort of more continuous leak. That class of bug is not (usually) a load-activated bug, though that class of bug could easily be secondary to another bug.

I posted the general code review list over in http://h71000.www7.hp.com/wizard/wiz_1661.html and some other threads referenced there.

Do ramp up on the new platform, too -- whatever that might be. Life's too short to stay grumpy, and I'm inferring you've got a case of the grumpies today. :-)


John McL
Trusted Contributor

Re: Memory leak

You've said nothing about the architecture of the application but that might be the cause of the problem.

Is it AST driven with a lot of network I/O and using a ring buffer that might be stressed by a heavy load? It's feasible that an initial buffer allocation is insufficient and further allocations are made, but the "expand" flag is not being cleared after an expansion is made. Perhaps previous input rates have never been enough to trigger this action (i.e. the buffer contents are processed fast enough so that the buffer never needed expansion) and the bug has not previously been exposed. If you are really lucky you'll have monitoring tools that tell you how many buffers are allocated and used.

Of course I might be barking up the wrong tree because I'm only guessing at how an application that processes Borse data might be structured.
labadie_1
Honored Contributor

Re: Memory leak

Volker Halle
Honored Contributor

Re: Memory leak

Wim,

is the application using PTHREADS ? Use ANAL/SYS and SDA> SET PROC FOE_RGS_SRV
Then try SDA> PTHREAD VM

If there is no error message, because the process is not threaded, is there any lookaside list with a substantial amount of packets ?

Volker.
John McL
Trusted Contributor

Re: Memory leak

You might also find the Tech Journal No. 7 article "Faking it with Open VMS Shareable Images" by John Gillings useful especially if you think the problem might be an errant LIB$GET_VM call.

The article is online at http://h71000.www7.hp.com/openvms/journal/v7/faking_it_with_openvms_shareable_images.html and the code seems to be downloadable.

Wim Van den Wyngaert
Honored Contributor

Re: Memory leak

All I know it's written in C.

Volker : pthread is unknown command in 7.3. Show proc/thr says "1 thread". May be retry when NYSE opens.

Nice article of John G. We used something simular on HP3000 to fool the verification of the license date of a certain product.

Labadie : ada ...

The applidcation boys will not look at the code and we now restart the process when it gets mad. BTW : when it gets mad it only takes a few minutes before the 1.5 GB is taken. Increasing it would only delay the problem a little.

Wim
Wim
Volker Halle
Honored Contributor

Re: Memory leak

Wim,

the SYS$SHARE:PTHREAD$SDA.EXE extension should be available since OpenVMS V7.2-1 ...

You can also check with SDA> SHOW PROC/CHAN, if PTHREAD$RTL is an activated image for this process.

Volker.
Robert Gezelter
Honored Contributor

Re: Memory leak

Wim,

"The applidcation boys will not look at the code and we now restart the process when it gets mad. BTW : when it gets mad it only takes a few minutes before the 1.5 GB is taken. Increasing it would only delay the problem a little."

I have had a few of those at clients over the years. Regrettably, the solution has often been to identify the failing code independently, and propose a fix. Not the best way to work, but it can be the most effective way to deal with organizational politics.

- Bob Gezelter, http://www.rlgsc.com
Wim Van den Wyngaert
Honored Contributor

Re: Memory leak

Bob,

Did that once (network connection was not closed). But after several years it's still not in production because of testing requirements.

In November we will have DRP tests and then I can reboot the node. May be it gets solved that way.

Volker,

I shortened the command to PTHR but this didn't work. When I typed it in full it worked. Sorry. Same conclusion : 1 thread.

Wim
Wim