Finding Memory Leaks (Round II)


Legendary Poster

Frosty had a thread a couple years ago - "Finding Memory Leaks" that got no responses.... Hopefully, "Round II" will get some advice?

- Heavily Customized System
- Recent Go Live, Billions of Users are Starting to Log in
- We are seeing some "out of heap", and other memory issues, occasionally, in crash logs (Kernel & Zombie, predominately)

Crash logs really don't share a lot of information - basically they tell us what might have been in use at the time something became viral and went all zombie on us.

So the question - during development, is there a formal process to identify what might be leaking?

There's an MSDN article - could this work during local development, then just remove the leak specific syntax during the development cycle:

What do you gurus do, out there, that helps identify you leaks?

Thanks in Advance!

Good topic. Where are you having "out of heap" errors. If on the ES then it very well could be memory leaks. If on the JAS server, well, Java doesn't have memory leaks right???? :)

I know there are tools out there for finding memory leaks in code but most of those require you to pretty much have complete control of the build process which, working within JDE toolset - namely busbuild, we don't necessarily have. Having said that, I think internally Oracle does use some of these tools, whether they only use them for TR level code or whether they also use if for business logic (i.e. BSFNs) as well I don't know. Would like to know if anyone out there has implemented any of these tools, if so, which ones and how, etc.

Other than good coding practices and using techniques that are less susceptible to memory leaks if there is a bug in the code I don't have any universal method of detecting memory leaks. For jdeCache related leaks (which could be argued aren't true memory leaks since memory at least gets free'd when the user session is terminated) you can review the logs on session termination to see which jdeCache instances still had records. Some of those are valid depending on the design pattern, but, if for instance the F42UI11/12 cache instances have records when a user logs out, you may have a problem. Just look for which jdeCache instances a) were not terminated at session termination and b) had records. For each one you will have to determine if that constitutes a memory leak or if the existence of the instance along with any records is by design.
The only one I am confident in discussing here is Open Close on table IO. There are other things you can do with C++ but I'm not that 100% on them.

All select fetch nexts need to to be wrapped in open close to open a bubble of memory and then pop it's bubble when done.
Important in subsystems and APPL screens. UBEs will end and free everything anyway.
Apart from the above you might also want to check on the netwrok & DB connections i have seen many times the connection timeout/lost during processing and kernel goes into zombies. If you can track the application or user during that time that can give much of usefull pointers to the issue.

Thanks guys,

- pretty much on-target for what I was expecting to read.... I mean, there is no easy way to find a smoking guy, just follow the smoke before the wind gets to it...

As John kind of touched on briefly. I think it is important to remember you can easily create resource leaks in ER code even if you never write a single line of C code. If you use BSFNs incorrectly and don't understand what is going on it is very easy to create resource leaks - just because you write only ER code doesn't mean you don't have to worry about such things.

You keep recommending an open/close when using table I/O.
Are you discussing ER or C++ coding?

Oops, have to change my signature to say MIGRATED!
Yes! Past tense! Woohoo!

You keep recommending an open/close when using table I/O.
Are you discussing ER or C++ coding?


Yeah good point, My C++ isn't that sharp so I'd struggle to code open/close in C++ off the bat, but ER coding Frosty.

But I would have thought the principle of IO management and memory would be the same, regardless of the source...? Due to the middleware sending the IO requests to the DB

I may get some T-shirts printed up. Open on the front, Close on the back ;)
Last edited:

Glad to hear of your migration.
Let us know when you migrate off the iSeries to the IBM Power Server running IBM I. IBM offers incentives to those still on iSeries.

Oops, have to change my signature to say MIGRATED!
Yes! Past tense! Woohoo!