Leaking

G

GregW

Member²
Have an app processing tens of thousands of transactions daily. Each transaction is processed by a newly-spawned thread that creates a data module containing a session and multiple queries. Any given transaction will use 1-3 of the query objects. Sessions are not pooled. Had been having AVs and such, but seem to have cleared them up with a mutex around Logon and CheckConnection calls. So everything's pretty much stable, but:

I seem to be leaking several MB per day. DOA 3.4.6, OCI 8.1.7, WinNT4 or 2k (2 installations). I suspect it's related to the transaction volume. A desk check of my code appears clean - all GetMems balanced, no premature Exits, all object allocations _seem_ to be freed. About to start the ball rolling on getting a good leak checker licensed, but in the meantime I notice that there are a few past threads about suspected leaks while logging on. While I'm waiting for the leak checker to show up, has there been any resolution to those threads?

G
 
There have been some Net8 versions with leaks in the past, but on Net8 8.1.7 this should be okay.

------------------
Marco Kalter
Allround Automations
 
Originally posted by mkalter:
There have been some Net8 versions with leaks in the past, but on Net8 8.1.7 this should be okay.
Click to expand...

Distinctly not okay. I've got, for the moment, an evaluation copy of MemorySleuth and it's flagging calls to TOracleSession.Logon. Additionally I put a new build out yesterday that uses DOA's internal pooling - and no other changes - and my leakage has doubled.
 
I did some additional tests, and depending on the Net8 version there is indeed a small memory leak (something like 50 - 100 bytes) when connecting and disconnecting a session. This seems like a Net8 bug, because it can be reproduced by just calling the corresponding OCI functions. We will investigate this further.

------------------
Marco Kalter
Allround Automations
 
Originally posted by mkalter:
This seems like a Net8 bug, because it can be reproduced by just calling the corresponding OCI functions. We will investigate this further.
Click to expand...

I'll be looking forward to hearing how that turns out. Anything I can do in the meantime to facilitate investigation? Alternatively, any thoughts on a workaround that might at least slow the leak?

G
 
At the moment the only work around I can think of is to reuse your TOracleSession instances without disconnecting and reconnecting them. You would have to implement your own session pool. This should reduce the leak to 0.

------------------
Marco Kalter
Allround Automations
 
Okay, this is just strange. I did my own pooling and I've been testing it on my desk for the last week. Today I needed to get the window out of the way and I minimized. My memory charge dropped like a stone; well below the initial launch. Then it started creeping back up. Restoring had no effect, but minimizing again repeated the effect. Then I tried on my production instances which are using DOA's pooling and saw the same thing. Never saw the leak with BDE so I don't know if the purge on minimize effect is there too. Does anyone know of any kind of lazy cleanup routine that might be invoked on minimize?

[This message has been edited by GregW (edited 21 June 2002).]
 
[YisraelE] Hello, GregW.
I have a same problem. Did you proceed to resolve this memory leak ?

Originally posted by GregW:
Okay, this is just strange. I did my own pooling and I've been testing it on my desk for the last week. Today I needed to get the window out of the way and I minimized. My memory charge dropped like a stone; well below the initial launch. Then it started creeping back up. Restoring had no effect, but minimizing again repeated the effect. Then I tried on my production instances which are using DOA's pooling and saw the same thing. Never saw the leak with BDE so I don't know if the purge on minimize effect is there too. Does anyone know of any kind of lazy cleanup routine that might be invoked on minimize?

[This message has been edited by GregW (edited 21 June 2002).]
Click to expand...
 
Originally posted by YisraelE:
[YisraelE] Hello, GregW.
I have a same problem. Did you proceed to resolve this memory leak ?
Click to expand...

Rolling something into production tomorrow. Unfortunately, our production volume is so high I can't generate a realistic test on my development machine, but I _think_ it will work. I'll post a real answer on Friday after we've had a few days to observe.

Following up my prior post, though, I was wrong about the minimize/restore trick. It's flushing the app's active memory, but I noticed that the VM allocation stays where it was.
 
Try calling:

SetProcessWorkingSetSize(GetCurrentProcess, dword(-1), dword(-1));

This should have the same effect as Minimize/Restore main window.You shouldn't call it too often, though, since it costs performance.

YisraelE.

------------------
 
Originally posted by GregW:
Rolling something into production tomorrow. Unfortunately, our production volume is so high I can't generate a realistic test on my development machine, but I _think_ it will work. I'll post a real answer on Friday after we've had a few days to observe.

Following up my prior post, though, I was wrong about the minimize/restore trick. It's flushing the app's active memory, but I noticed that the VM allocation stays where it was.
Click to expand...
 
Marco, is there any news on your investigation of this leakage yet? Can you confirm that this is net8 and not a doa problem? Any new workarounds?

Thanks,
jeroen

Originally posted by mkalter:
I did some additional tests, and depending on the Net8 version there is indeed a small memory leak (something like 50 - 100 bytes) when connecting and disconnecting a session. This seems like a Net8 bug, because it can be reproduced by just calling the corresponding OCI functions. We will investigate this further.
Click to expand...
 
I can confirm that this is an Oracle Net issue. At this moment, I do not know of any other work arounds than mentioned above.

------------------
Marco Kalter
Allround Automations
 
Marco, installing 8.1.7.4 client fixes the leak.

regards,
jeroen

Originally posted by mkalter:
I can confirm that this is an Oracle Net issue. At this moment, I do not know of any other work arounds than mentioned above.
Click to expand...
 
You must log in or register to reply here.
Back
Top