Board index » jbuilder » Memory Leaks

Memory Leaks


2003-08-18 08:51:38 PM
jbuilder22
Hi.
I've reported this error several times, but I still have to re-start
JBuilder 6.0 about every hour as it freezes with "out of memory error".
I have plenty of memory on my PC, have all the windows updates, have update
to JB 6, but to no avail.
Ted
 
 

Re:Memory Leaks

Ted:
The amount of memory on your computer has very little to do with
java.lang.OutOfMemory errors. When the VM heap is maxed out, you are
out of memory. Increase the heap for JBuilder (in the jbuilder config
look for the -mx parameter and up the number). For more, read up on JVM
parameters at javasoft.com.
-Rich
Ted Reilly wrote:
Quote
Hi.

I've reported this error several times, but I still have to re-start
JBuilder 6.0 about every hour as it freezes with "out of memory error".

I have plenty of memory on my PC, have all the windows updates, have update
to JB 6, but to no avail.

Ted




 

Re:Memory Leaks

JB6 is not stable, that is why I went back to JB5 sometimes ago
-D
"Rich Wilkman" < XXXX@XXXXX.COM >wrote in message
Quote
Ted:

The amount of memory on your computer has very little to do with
java.lang.OutOfMemory errors. When the VM heap is maxed out, you are
out of memory. Increase the heap for JBuilder (in the jbuilder config
look for the -mx parameter and up the number). For more, read up on JVM
parameters at javasoft.com.

-Rich

Ted Reilly wrote:

>Hi.
>
>I've reported this error several times, but I still have to re-start
>JBuilder 6.0 about every hour as it freezes with "out of memory error".
>
>I have plenty of memory on my PC, have all the windows updates, have
update
>to JB 6, but to no avail.
>
>Ted
>
>
>
>

 

{smallsort}

Re:Memory Leaks

When we last upgraded ( i don't remember exactly when; just after borland
took over) the upgrade presented problems when the desktop was setup for
'single click' icons. That is you click once to start a function instead of
dbl click. CodeWrite inherited this setting from the desktop and we found
that when you move the cursor over files in the Project tab, it wouldn't be
long before Windows would run out of resources and you would have to reboot
to get resources back. This was especially bad on W98. I turned off the
option in the desktop to get around the problem. I now use XP. It has the
same problem only it takes longer since I have more ram. We have ver 7.5.
Does anyone know if this has been fixed or if there is some way to disable
the 'single click' option in CodeWrite?
 

Re:Memory Leaks

I found a guy who had the same complaint three years ago. But still the codewright has the issue. I do not believe this.
"MAO" <nospamplease.com>wrote:
Quote
When we last upgraded ( i don't remember exactly when; just after borland
took over) the upgrade presented problems when the desktop was setup for
'single click' icons. That is you click once to start a function instead of
dbl click. CodeWrite inherited this setting from the desktop and we found
that when you move the cursor over files in the Project tab, it wouldn't be
long before Windows would run out of resources and you would have to reboot
to get resources back. This was especially bad on W98. I turned off the
option in the desktop to get around the problem. I now use XP. It has the
same problem only it takes longer since I have more ram. We have ver 7.5.
Does anyone know if this has been fixed or if there is some way to disable
the 'single click' option in CodeWrite?


 

Re:Memory Leaks

I reported this bug about two years ago. Back then Borland told me that I
was the only one having this problem. After about a year we found out that
'single click' was the reason for the memory leaks.
This is fixed now - are you using the latest 7.5 build?
Christof
----------------
Hello Anom,
Quote
I found a guy who had the same complaint three years ago. But still
the codewright has the issue. I do not believe this.

"MAO" <nospamplease.com>wrote:

>When we last upgraded ( i don't remember exactly when; just after
>borland took over) the upgrade presented problems when the desktop
>was setup for 'single click' icons. That is you click once to start a
>function instead of dbl click. CodeWrite inherited this setting from
>the desktop and we found that when you move the cursor over files in
>the Project tab, it wouldn't be long before Windows would run out of
>resources and you would have to reboot to get resources back. This
>was especially bad on W98. I turned off the option in the desktop to
>get around the problem. I now use XP. It has the same problem only it
>takes longer since I have more ram. We have ver 7.5. Does anyone know
>if this has been fixed or if there is some way to disable the 'single
>click' option in CodeWrite?
>
 

Re:Memory Leaks

No I'm not using the latest build. I will have to see about getting it.
I'm not sure what you mean about 'Single Click'. On windows 98, we didn't
have to click. We activated the 'Resource Meter' and then just moved the
cursor up and down the Project Window in CodeWrite and watched the resource
meter decrease until the resources ran out.
Thanks
"Christof Nef" < XXXX@XXXXX.COM >wrote in message
Quote
I reported this bug about two years ago. Back then Borland told me that I
was the only one having this problem. After about a year we found out that
'single click' was the reason for the memory leaks.
This is fixed now - are you using the latest 7.5 build?

Christof

----------------
Hello Anom,

>I found a guy who had the same complaint three years ago. But still
>the codewright has the issue. I do not believe this.
>
>"MAO" <nospamplease.com>wrote:
>
>>When we last upgraded ( i don't remember exactly when; just after
>>borland took over) the upgrade presented problems when the desktop
>>was setup for 'single click' icons. That is you click once to start a
>>function instead of dbl click. CodeWrite inherited this setting from
>>the desktop and we found that when you move the cursor over files in
>>the Project tab, it wouldn't be long before Windows would run out of
>>resources and you would have to reboot to get resources back. This
>>was especially bad on W98. I turned off the option in the desktop to
>>get around the problem. I now use XP. It has the same problem only it
>>takes longer since I have more ram. We have ver 7.5. Does anyone know
>>if this has been fixed or if there is some way to disable the 'single
>>click' option in CodeWrite?
>>



 

Re:Memory Leaks

hi, i downloaded memproof but i'm not sure which values are important for me to learn if my application has memory leaks or not. is there anyone who has experienced with ? and do you know any other free memory tool like memproof ?
regards,
 

Re:Memory Leaks

Quote
hi, i downloaded memproof but i'm not sure which values are important for
me to learn if my application has memory leaks or not. is there anyone who
has experienced with ? and do you know any other free memory tool like
memproof ?
v.mahon.free.fr/pro/freeware/memcheck/
MemCheck does not work like Memproof but is a very usefull tool for
detecting memory leaks.
Best regards,
Paul Hectors
 

Re:Memory Leaks

Cheers,
I used the FastMM, FastMove, FastObj on my Intraweb Application and I must
say that its a great tool for viewing the memory leaks that an app is
generating.
Now, I was able to get rid of all the Memory Leaks that I have control over,
but still Im left with a few memory leaks that I dont think I have control
over.
These are the following:
TIDThreadSafeInteger
TInThreadSafeInteger
TIDSMTPEnhancedCode
TIDCriticalSection
TIDSSLOptions
I reckon that this are all Indy Components that are generating this leaks,
now my question is, are these really memory leaks? and if so how do I get
rid of these?
TIA
Randy.
 

Re:Memory Leaks

Randy Adanza wrote:
Quote
These are the following:
TIDThreadSafeInteger
TInThreadSafeInteger
TIDSMTPEnhancedCode
TIDCriticalSection
TIDSSLOptions

I reckon that this are all Indy Components that are generating this leaks,
now my question is, are these really memory leaks? and if so how do I get
rid of these?
I know that Indy intentionally leaks at least one critical section. If
you use a tool to track down the location where the leaked objects are
created you may be able to identify the other leaks. I suggest Memproof:
www.automatedqa.com/downloads/memproof/
or Memcheck:
v.mahon.free.fr/pro/freeware/memcheck/
Cheers,
Nicholas Sherlock
 

Re:Memory Leaks

"Randy Adanza" < XXXX@XXXXX.COM >wrote in message
Quote
Cheers,

I used the FastMM, FastMove, FastObj on my Intraweb Application and I must
say that its a great tool for viewing the memory leaks that an app is
generating.
Now, I was able to get rid of all the Memory Leaks that I have control
over, but still Im left with a few memory leaks that I dont think I have
control over.
These are the following:
TIDThreadSafeInteger
TInThreadSafeInteger
TIDSMTPEnhancedCode
TIDCriticalSection
TIDSSLOptions

I reckon that this are all Indy Components that are generating this leaks,
now my question is, are these really memory leaks? and if so how do I get
rid of these?
FastMM definitely should allow to track those memory leaks. Otherwise, as
Nicholas said, Indy does have known and "valid" leaks. I also use Indy and
to ignore its leaks, I had to add those two lines at the very beginning of
my code:
RegisterExpectedMemoryLeak(TIdThreadSafeInteger, 1);
RegisterExpectedMemoryLeak(TIdCriticalSection, 2);
Hope that helps,
Alan.
 

Re:Memory Leaks

Quote
>few memory leaks that I dont think I have control over. These are
>the following: TIDThreadSafeInteger TInThreadSafeInteger
>TIDSMTPEnhancedCode TIDCriticalSection
>TIDSSLOptions
>
>I reckon that this are all Indy Components that are generating this
>leaks, now my question is, are these really memory leaks? and if
>so how do I get rid of these?
Otherwise, as Nicholas said, Indy does have known and "valid" leaks.
I also use Indy and to ignore its leaks, I had to add those two lines
at the very beginning of my code:

RegisterExpectedMemoryLeak(TIdThreadSafeInteger, 1);
RegisterExpectedMemoryLeak(TIdCriticalSection, 2);
Reply is to Randy, from Alan's response ;-)
The indy ones are leaks that happen only as an application shuts down,
so you are safe to ignore them.
Intraweb uses a private internal fork of indy to give them a fixed
codebase. The fork IIRC renames things : IN* instead of ID*.
My intraweb apps usually have the 2 indy items (above) and 2 identical
ones with TIN* instead. I can't remove them since I don't have the fork
source to link against and register correctly.
You can ignore them also, since they are from the same root cause,
Indy, and only get leaked as the app shuts down. Right after, the app
completes close and gives all memory back anyhow.
Not sure at all why you are getting
TIDSMTPEnhancedCode
TIDSSLOptions
but I don't use those elements of indy.
I use fastmm with all apps including many IW ones. I have no problems.
I tend to comment out the Fast* things when developing tho, to help
debugging. I don't want to step into fastcode while looking for my own
logic or code errors :)
Many apps deployed using FastMM & various Fastcode routines with no
issues relating to fast-anything, only speed increases.
 

Re:Memory Leaks

Thanks for the info guys.
"Rick Hoskins" < XXXX@XXXXX.COM >wrote in message
Quote

>>few memory leaks that I dont think I have control over. These are
>>the following: TIDThreadSafeInteger TInThreadSafeInteger
>>TIDSMTPEnhancedCode TIDCriticalSection
>>TIDSSLOptions
>>
>>I reckon that this are all Indy Components that are generating this
>>leaks, now my question is, are these really memory leaks? and if
>>so how do I get rid of these?

>Otherwise, as Nicholas said, Indy does have known and "valid" leaks.
>I also use Indy and to ignore its leaks, I had to add those two lines
>at the very beginning of my code:
>
>RegisterExpectedMemoryLeak(TIdThreadSafeInteger, 1);
>RegisterExpectedMemoryLeak(TIdCriticalSection, 2);

Reply is to Randy, from Alan's response ;-)

The indy ones are leaks that happen only as an application shuts down,
so you are safe to ignore them.
Intraweb uses a private internal fork of indy to give them a fixed
codebase. The fork IIRC renames things : IN* instead of ID*.

My intraweb apps usually have the 2 indy items (above) and 2 identical
ones with TIN* instead. I can't remove them since I don't have the fork
source to link against and register correctly.
You can ignore them also, since they are from the same root cause,
Indy, and only get leaked as the app shuts down. Right after, the app
completes close and gives all memory back anyhow.

Not sure at all why you are getting
TIDSMTPEnhancedCode
TIDSSLOptions
but I don't use those elements of indy.
I use fastmm with all apps including many IW ones. I have no problems.
I tend to comment out the Fast* things when developing tho, to help
debugging. I don't want to step into fastcode while looking for my own
logic or code errors :)

Many apps deployed using FastMM & various Fastcode routines with no
issues relating to fast-anything, only speed increases.
 

Re:Memory Leaks

I posted a query recently about the receiving the error "OutOfMemory in
FREEUDBLib.dll". Since then I have re-compiled this dll, flagging it to use
FREEIT and not thread local variables, restarted the server only to have the
same problem occur in about 5 days.
I have been monitoring the server's memory use and it has been increasing
significantly every day. Now I'm unsure whether it's the UDF lib causing the
problem or something else - I guess the error message could be the result of
the UDF lib requesting memory first, but not necessarily the cause??
In any case, how should I go about diagnosing memory leaks?
Thanks in advance
Russell.