Re: 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>