You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Forrest Girouard <Fo...@openwave.com> on 2004/03/04 00:15:52 UTC
native memory leak on every call to File.deleteOnExit()
Folks:
Is any one on this list aware that every call to File.deleteOnExit()
leaks memory in the native heap? This eventually crashes the JVM.
Please see
http://developer.java.sun.com/developer/bugParade/bugs/4513817.html.
It seems to me that the call to deleteOnExit() from
DefaultFileItem.getTempFile() is premature and that it should really be
called from DeferredFileOutputStream.thresholdReached(). Thoughts?
Cheers,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Forrest Girouard <Fo...@openwave.com>.
On Mar 3, 2004, at 4:42 PM, Tomasz Pik wrote:
> Forrest Girouard wrote:
>
>> On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>>>> Is any one on this list aware that every call to File.deleteOnExit()
>>>> leaks memory in the native heap?
>>>
>>> I am. Code intended for server use should be audited to remove that
>>> call.
>> Ok. I wasn't aware that there were any expectations in this area.
>> Can you explain further? Is there other calls that need to be
>> "removed" for server use?
>
> If you're asking about Java libraries, not directly commons libraries
> I know two examples, that cause problems with webapp classloaders
> and reloading: adding SecurityProviders and loading native libraries.
Thanks for the input although I'm aware of the issues surrounding these
two examples. By the way, we completely avoid all the native code
issues of which there are many by simply having a local surrogate
process make those calls on our behalf.
Cheers,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Forrest Girouard <Fo...@openwave.com>.
On Mar 3, 2004, at 4:42 PM, Tomasz Pik wrote:
> Forrest Girouard wrote:
>
>> On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>>>> Is any one on this list aware that every call to File.deleteOnExit()
>>>> leaks memory in the native heap?
>>>
>>> I am. Code intended for server use should be audited to remove that
>>> call.
>> Ok. I wasn't aware that there were any expectations in this area.
>> Can you explain further? Is there other calls that need to be
>> "removed" for server use?
>
> If you're asking about Java libraries, not directly commons libraries
> I know two examples, that cause problems with webapp classloaders
> and reloading: adding SecurityProviders and loading native libraries.
Thanks for the input although I'm aware of the issues surrounding these
two examples. By the way, we completely avoid all the native code
issues of which there are many by simply having a local surrogate
process make those calls on our behalf.
Cheers,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Tomasz Pik <pi...@ais.pl>.
Forrest Girouard wrote:
> On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>
>>> Is any one on this list aware that every call to File.deleteOnExit()
>>> leaks memory in the native heap?
>>
>>
>> I am. Code intended for server use should be audited to remove that
>> call.
>
>
> Ok. I wasn't aware that there were any expectations in this area. Can
> you explain further? Is there other calls that need to be "removed" for
> server use?
If you're asking about Java libraries, not directly commons libraries
I know two examples, that cause problems with webapp classloaders
and reloading: adding SecurityProviders and loading native libraries.
Regards,
Tomek
> Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Tomasz Pik <pi...@ais.pl>.
Forrest Girouard wrote:
> On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>
>>> Is any one on this list aware that every call to File.deleteOnExit()
>>> leaks memory in the native heap?
>>
>>
>> I am. Code intended for server use should be audited to remove that
>> call.
>
>
> Ok. I wasn't aware that there were any expectations in this area. Can
> you explain further? Is there other calls that need to be "removed" for
> server use?
If you're asking about Java libraries, not directly commons libraries
I know two examples, that cause problems with webapp classloaders
and reloading: adding SecurityProviders and loading native libraries.
Regards,
Tomek
> Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: native memory leak on every call to File.deleteOnExit()
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm well aware of bug id 4513817 [but] inferred perhaps incorrectly
> from your comment that there is a well-known process under which
> Jakarta components must be handled in order to be used in a server
> setting.
No. That standard Java API should never be used in any long running
process, having nothing to do with Jakarta.
> > If no one gets to this, I might hack a TemporaryFile class, but I've
> > got higher priority items on my plate at the moment.
> In case it's not obvious nothing has higher priority for me at the
> moment, I'm on this 24/7 until I have a work around and/or solution.
Wasn't obvious. If your need is that urgent and no one else bites, contact
me off-list.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Forrest Girouard <Fo...@openwave.com>.
On Mar 3, 2004, at 6:18 PM, Noel J. Bergman wrote:
>>>> Is any one on this list aware that every call to File.deleteOnExit()
>>>> leaks memory in the native heap?
>>> I am. Code intended for server use should be audited to remove that
>>> call.
>
>> I wasn't aware that there were any expectations in this area. Can
>> you explain further?
>
> See the bug parade. I suspect I know whose quotes are there
> explaining the
> problem.
I'm well aware of bug id 4513817
(http://developer.java.sun.com/developer/bugParade/bugs/4513817.html)
but inferred perhaps incorrectly from your comment that there is a
well-known process under which Jakarta components must be handled in
order to be used in a server setting.
>>> If someone wants to create an alternative using phantom
>>> references, that would be fine, and generally useful.
>
>> I know what phantom references are in theory but I've not yet used
>> them
>> personally. Can you give me any further information on how this might
>> be done?
>
> See:
> http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-java101.html for
> an intro to PhantomeReferences.
Like I said I know what PhantomReferences are I just wanted to know how
you thought they might be most effectively employed for the issue at
hand.
> If no one gets to this, I might hack a TemporaryFile class, but I've
> got
> higher priority items on my plate at the moment.
In case it's not obvious nothing has higher priority for me at the
moment, I'm on this 24/7 until I have a work around and/or solution.
Cheers,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: native memory leak on every call to File.deleteOnExit()
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> Is any one on this list aware that every call to File.deleteOnExit()
>>> leaks memory in the native heap?
>> I am. Code intended for server use should be audited to remove that
>> call.
> I wasn't aware that there were any expectations in this area. Can
> you explain further?
See the bug parade. I suspect I know whose quotes are there explaining the
problem.
> Is there other calls that need to be "removed" for server use?
Of this nature? Not that comes to mind off-hand.
>> If someone wants to create an alternative using phantom
>> references, that would be fine, and generally useful.
> I know what phantom references are in theory but I've not yet used them
> personally. Can you give me any further information on how this might
> be done?
See: http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-java101.html for
an intro to PhantomeReferences.
If no one gets to this, I might hack a TemporaryFile class, but I've got
higher priority items on my plate at the moment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: native memory leak on every call to File.deleteOnExit()
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> Is any one on this list aware that every call to File.deleteOnExit()
>>> leaks memory in the native heap?
>> I am. Code intended for server use should be audited to remove that
>> call.
> I wasn't aware that there were any expectations in this area. Can
> you explain further?
See the bug parade. I suspect I know whose quotes are there explaining the
problem.
> Is there other calls that need to be "removed" for server use?
Of this nature? Not that comes to mind off-hand.
>> If someone wants to create an alternative using phantom
>> references, that would be fine, and generally useful.
> I know what phantom references are in theory but I've not yet used them
> personally. Can you give me any further information on how this might
> be done?
See: http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-java101.html for
an intro to PhantomeReferences.
If no one gets to this, I might hack a TemporaryFile class, but I've got
higher priority items on my plate at the moment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Forrest Girouard <Fo...@openwave.com>.
On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>> Is any one on this list aware that every call to File.deleteOnExit()
>> leaks memory in the native heap?
>
> I am. Code intended for server use should be audited to remove that
> call.
Ok. I wasn't aware that there were any expectations in this area. Can
you explain further? Is there other calls that need to be "removed"
for server use?
> It is not a bug. It is working as designed (the merit of that design
> being
Ok.
> beside the point). If someone wants to create an alternative using
> phantom
> references, that would be fine, and generally useful.
I know what phantom references are in theory but I've not yet used them
personally. Can you give me any further information on how this might
be done?
Thanks,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: native memory leak on every call to File.deleteOnExit()
Posted by Forrest Girouard <Fo...@openwave.com>.
On Mar 3, 2004, at 4:05 PM, Noel J. Bergman wrote:
>> Is any one on this list aware that every call to File.deleteOnExit()
>> leaks memory in the native heap?
>
> I am. Code intended for server use should be audited to remove that
> call.
Ok. I wasn't aware that there were any expectations in this area. Can
you explain further? Is there other calls that need to be "removed"
for server use?
> It is not a bug. It is working as designed (the merit of that design
> being
Ok.
> beside the point). If someone wants to create an alternative using
> phantom
> references, that would be fine, and generally useful.
I know what phantom references are in theory but I've not yet used them
personally. Can you give me any further information on how this might
be done?
Thanks,
Forrest
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: native memory leak on every call to File.deleteOnExit()
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Is any one on this list aware that every call to File.deleteOnExit()
> leaks memory in the native heap?
I am. Code intended for server use should be audited to remove that call.
It is not a bug. It is working as designed (the merit of that design being
beside the point). If someone wants to create an alternative using phantom
references, that would be fine, and generally useful.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: native memory leak on every call to File.deleteOnExit()
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Is any one on this list aware that every call to File.deleteOnExit()
> leaks memory in the native heap?
I am. Code intended for server use should be audited to remove that call.
It is not a bug. It is working as designed (the merit of that design being
beside the point). If someone wants to create an alternative using phantom
references, that would be fine, and generally useful.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org