Memory management tools for HP-UX?

[Mike Stroyan]

A 1GB limit is likely to come from the way you link your program. The default linker behavior puts the data region at addresses starting at 1GB and extending to about 2GB. Using a compiler option of -Wl,-N will pass the linker a -N option with starts the data area just above the text area. That will allow almost 2GB of data area as long as you don't reach another limit such as maxdsiz, ulimit or available swap space.

The wdb debugger has a simple memory leak checker in it. You can get the most current wdb from http://www.hp.com/go/wdb .

[Paddy_1]

Actually Clay has a point in saying that the runtime library interaction to be suspect.

IBM has a memory interceptor library thats Free and available for download at :
http://www.alphaworks.ibm.com/tech/mil

-Paddy

[Ted Buis]

This is not a fix, but if you have Process Resource Manager you could limit the amount of real memory that the application gets to use, and keep it from totally impacting other applications. Not really a long term solution, but something that might help in the short term.

[Steve Zwach]

We have updated our compiler to the 3.52 version and the linker version is at 11.38 but Purify still core dumps when we try to run. Are there any extra tricks or something in the setup that we need to do to get Purify to run on this HP machine? I was hoping that the new compiler would make it easier to run but that is not the case, and the requirements for Purify don't even list the new version of the compiler so I am wondering if this is supported at all.

[Peter Hug]

Steve, did you manage to get your software working? If yes, what did you end up doing?

[Steve Zwach]

Here is an update. After we updated to the newest compiler 3.52, then we tried to get purify to work and again it failed. Then we called IBM Rational to get their help and they have not been any help yet! First they said that they don't support that version of the compiler so we went to 3.45 which IBM said is the latest version they support and agin we fail in the same way. Right now after almost five weeks they said they think they have a bug have sent the problem to thier support team in India to look at. Apparantly they said it should be a two week turnaround! Long story short we still don't have the problem fixed.

We did find a way to link the process so that it can grow to over a gig but our client doesn't feel that is a solution.

[Lalit Seth]

Hi Steve,

What all flags and technique to used to link the process so that it doesn't do core dump after crossing 1G restriction.

Many Thanks
Lalit

[David Gourley_1]

Just a couple of comments from my experience in this area.

1) Purify doesn't catch all types of memory "leak"; we had an algorithmic problem where memory was being added to an internal (complex) data structure, and not being removed correctly. When our process exited, the memory structure was cleaned up properly, so Purify didn't detect the problem (as we didn't have a classic leak; we had a logic bomb).

2) We've also encountered scenarios where the algorithms in a process were such that the process could grow to > maxdsize (with the inevitable core dump).

3) Where we've had problems with purify, and to address (1) or (2), we've instrumented our code by logging the size of a process's data segment (found by calling pstat_getproc). This can help pin down exactly where in your code a process is growing (which is the first step to working out why it's growing).