Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/26/2010 05:26 PM, Chris Rider wrote: As you can tell from the log file, the close method is being called, but not the dispose. Do I need to dispose also? Couldn't really find enough documentation to figure out *exactly* what those two methods entail. I kind of assumed it was something like the difference between clearing the objects memory or not. No, it a component supports XCloseable, you must call close(), otherwise dispose(). As close() will call dispose() internally, all you can get from an explicit dispose() call is a DisposedException. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/25/2010 07:10 PM, Chris Rider wrote: We are using DocumentLoader to manage the opening of PowerPoint files, and have recently discovered what appears to be a memory leak. As a quick background, these are self-advancing presentations, created using Microsoft by the end-user, who then uses our product (CentOS based) to display the files. When the cleanup routine is called, it appears to do its thing, but a bit of time later, the machine is almost frozen from all of its memory being used up... and after taking a look at the processes on the machine, we tracked it back to this. Below is from our log file... It looks like it reaches the end of the slideshow (event OnEndPresentation) and fires the Cleanup routine... but is it working past that point? Appears to not be. Are there any known issues with this sort of thing? Anyone else seeing this? Thanks! Chris 1288025660 : pid: 6935 - Acquiring lock... 1288025660 : pid: 6935 - Lock acquired! 1288025660 : pid: 6935 - Connected successfully to the office 1288025660 : pid: 6935 - XComponentloader successfully instantiated 1288025660 : pid: 6935 - argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025660 : pid: 6935 - Document: file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025661 : pid: 6935 - Starting Presentation... 1288025661 : pid: 6935 - Presentation Started! 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Releasing lock... 1288025661 : pid: 6935 - Lock released! 1288025661 : pid: 6935 - Wait for end! 1288025661 : pid: 6935 - Event : OnUnfocus received 1288025661 : pid: 6935 - Event : OnStartPresentation received 1288025661 : pid: 6935 - Event : OnFocus received 1288025661 : pid: 6935 - Event : OnLoad received 1288025662 : pid: 6935 - Event : OnEndPresentation received 1288025662 : pid: 6935 - Ending! 1288025662 : pid: 6935 - Event : OnViewClosed received 1288025662 : pid: 6935 - Event : OnUnfocus received 1288025664 : pid: 6935 - Cleanup 1288025664 : pid: 6935 - Cleanup - close - dispose I don't know how you created your logs, but at least in this log I don't see traces of the document being closed (Event OnClose, disposing etc.). But maybe that's part of the last line. Besides that, the document being closed does not mean that it is removed from memory. It's possible that it is still referenced somewhere and so the object is not destroyed. I think that eating up the memory completely - as you described it - would require thousands of such dangling references, but you never know. So look for references to documents (models) in your code. In case your application is implemented in Java, don't rely on the garbage collection doing the work for you, it might kick in just too late. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
I'm just creating logs with a function (see below for example)
I'm pretty sure it isn't being referenced anywhere else. We are merely
using this to initiate opening of the file.
Here is my C++ function...
void Cleanup(const Reference XComponent component) {
WriteLog( pid: %d - Cleanup\n, getpid() );
Reference XCloseable xCloseable(component, UNO_QUERY);
if ( xCloseable.is() ) {
WriteLog( pid: %d - Cleanup - close - dispose\n, getpid() );
xCloseable-close(false);
} else {
WriteLog( pid: %d - Cleanup - dispose\n, getpid() );
component-dispose();
}
}
As you can tell from the log file, the close method is being called, but
not the dispose.
Do I need to dispose also? Couldn't really find enough documentation to
figure out *exactly* what those two methods entail. I kind of assumed it
was something like the difference between clearing the objects memory or
not.
Besides any concern for other references being possibly needed (I highly
doubt there are any of consequence), it probably couldn't hurt to
dispose right after closing, within the same true if condition (?)
Thanks!
Chris
On 10/26/2010 03:00 AM, Mathias Bauer wrote:
On 10/25/2010 07:10 PM, Chris Rider wrote:
We are using DocumentLoader to manage the opening of PowerPoint files,
and have recently discovered what appears to be a memory leak.
As a quick background, these are self-advancing presentations, created
using Microsoft by the end-user, who then uses our product (CentOS
based) to display the files.
When the cleanup routine is called, it appears to do its thing, but a
bit of time later, the machine is almost frozen from all of its memory
being used up... and after taking a look at the processes on the
machine, we tracked it back to this.
Below is from our log file...
It looks like it reaches the end of the slideshow (event
OnEndPresentation) and fires the Cleanup routine... but is it working
past that point? Appears to not be.
Are there any known issues with this sort of thing? Anyone else seeing
this?
Thanks!
Chris
1288025660 : pid: 6935 - Acquiring lock...
1288025660 : pid: 6935 - Lock acquired!
1288025660 : pid: 6935 - Connected successfully to the office
1288025660 : pid: 6935 - XComponentloader successfully instantiated
1288025660 : pid: 6935 -
argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025660 : pid: 6935 - Document:
file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025661 : pid: 6935 - Starting Presentation...
1288025661 : pid: 6935 - Presentation Started!
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Releasing lock...
1288025661 : pid: 6935 - Lock released!
1288025661 : pid: 6935 - Wait for end!
1288025661 : pid: 6935 - Event : OnUnfocus received
1288025661 : pid: 6935 - Event : OnStartPresentation received
1288025661 : pid: 6935 - Event : OnFocus received
1288025661 : pid: 6935 - Event : OnLoad received
1288025662 : pid: 6935 - Event : OnEndPresentation received
1288025662 : pid: 6935 - Ending!
1288025662 : pid: 6935 - Event : OnViewClosed received
1288025662 : pid: 6935 - Event : OnUnfocus received
1288025664 : pid: 6935 - Cleanup
1288025664 : pid: 6935 - Cleanup - close - dispose
I don't know how you created your logs, but at least in this log I
don't see traces of the document being closed (Event OnClose,
disposing etc.). But maybe that's part of the last line.
Besides that, the document being closed does not mean that it is
removed from memory. It's possible that it is still referenced
somewhere and so the object is not destroyed. I think that eating up
the memory completely - as you described it - would require thousands
of such dangling references, but you never know.
So look for references to documents (models) in your code. In case
your application is implemented in Java, don't rely on the garbage
collection doing the work for you, it might kick in just too late.
Regards,
Mathias
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
Please disregard / delete / etc this thread...
I am merging this to another post
On 10/26/2010 11:26 AM, Chris Rider wrote:
I'm just creating logs with a function (see below for example)
I'm pretty sure it isn't being referenced anywhere else. We are merely
using this to initiate opening of the file.
Here is my C++ function...
void Cleanup(const Reference XComponent component) {
WriteLog( pid: %d - Cleanup\n, getpid() );
Reference XCloseable xCloseable(component, UNO_QUERY);
if ( xCloseable.is() ) {
WriteLog( pid: %d - Cleanup - close - dispose\n, getpid() );
xCloseable-close(false);
} else {
WriteLog( pid: %d - Cleanup - dispose\n, getpid() );
component-dispose();
}
}
As you can tell from the log file, the close method is being called,
but not the dispose.
Do I need to dispose also? Couldn't really find enough documentation
to figure out *exactly* what those two methods entail. I kind of
assumed it was something like the difference between clearing the
objects memory or not.
Besides any concern for other references being possibly needed (I
highly doubt there are any of consequence), it probably couldn't hurt
to dispose right after closing, within the same true if condition (?)
Thanks!
Chris
On 10/26/2010 03:00 AM, Mathias Bauer wrote:
On 10/25/2010 07:10 PM, Chris Rider wrote:
We are using DocumentLoader to manage the opening of PowerPoint files,
and have recently discovered what appears to be a memory leak.
As a quick background, these are self-advancing presentations, created
using Microsoft by the end-user, who then uses our product (CentOS
based) to display the files.
When the cleanup routine is called, it appears to do its thing, but a
bit of time later, the machine is almost frozen from all of its memory
being used up... and after taking a look at the processes on the
machine, we tracked it back to this.
Below is from our log file...
It looks like it reaches the end of the slideshow (event
OnEndPresentation) and fires the Cleanup routine... but is it working
past that point? Appears to not be.
Are there any known issues with this sort of thing? Anyone else seeing
this?
Thanks!
Chris
1288025660 : pid: 6935 - Acquiring lock...
1288025660 : pid: 6935 - Lock acquired!
1288025660 : pid: 6935 - Connected successfully to the office
1288025660 : pid: 6935 - XComponentloader successfully instantiated
1288025660 : pid: 6935 -
argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025660 : pid: 6935 - Document:
file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025661 : pid: 6935 - Starting Presentation...
1288025661 : pid: 6935 - Presentation Started!
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Releasing lock...
1288025661 : pid: 6935 - Lock released!
1288025661 : pid: 6935 - Wait for end!
1288025661 : pid: 6935 - Event : OnUnfocus received
1288025661 : pid: 6935 - Event : OnStartPresentation received
1288025661 : pid: 6935 - Event : OnFocus received
1288025661 : pid: 6935 - Event : OnLoad received
1288025662 : pid: 6935 - Event : OnEndPresentation received
1288025662 : pid: 6935 - Ending!
1288025662 : pid: 6935 - Event : OnViewClosed received
1288025662 : pid: 6935 - Event : OnUnfocus received
1288025664 : pid: 6935 - Cleanup
1288025664 : pid: 6935 - Cleanup - close - dispose
I don't know how you created your logs, but at least in this log I
don't see traces of the document being closed (Event OnClose,
disposing etc.). But maybe that's part of the last line.
Besides that, the document being closed does not mean that it is
removed from memory. It's possible that it is still referenced
somewhere and so the object is not destroyed. I think that eating up
the memory completely - as you described it - would require thousands
of such dangling references, but you never know.
So look for references to documents (models) in your code. In case
your application is implemented in Java, don't rely on the garbage
collection doing the work for you, it might kick in just too late.
Regards,
Mathias
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
