dbaccess::ODatabaseContext cleaning its cache "too late"?

[Michael Stahl]

On 10/09/13 18:40, Lionel Elie Mamane wrote:

> 2) Run a python script like
> 
>    import uno
>    localContext = uno.getComponentContext()
> 
>    resolver = localContext.ServiceManager.createInstanceWithContext(
> 			"com.sun.star.bridge.UnoUrlResolver", localContext )
> 
>    ctx = resolver.resolve("uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext" )
>    smgr = ctx.ServiceManager
>    dbCtx =  smgr.createInstanceWithContext( "com.sun.star.sdb.DatabaseContext",ctx)
> 
> 
> The ODatabaseContext that just got created, to what window would it be
> tied?
> 
>> or some "shell" in sfx2 speak,
> 
> Is the notion of "shell" different than "window"? Would the above
> scenario have a shell, but no window?

specifically some SfxViewShell or SfxObjectShell... which dbaccess
doesn't use.  it probably has some other implementation of
css;:frame::XFrame/XModel though.

but in this case of course there's no XFrame in sight; one could expect
the service instance to be destroyed when dbCtx is reset... unless it
needs an explicit close() or dispose()...

the question is when this happens in end user scenario like the below
bug report, is the database context tied to some document or not;
perhaps the document is _also_ leaked?  (see also
http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Closing_Documents
)

> In the context of https://bugs.freedesktop.org/69036, I would like to
> see who holds a reference to the DatabaseContext that gets closed. It
> is my understanding that (because we have reference-counting garbage
> collection), dispose() should actually be called as soon as nobody
> holds a reference to it anymore (unless we have a reference cycle).

dispose() may sometimes be used as a way of breaking a reference cycle,
causing one of the reference to be released.

> How can I find that out? Anything better than breaking on the
> constructor and going a few frames up, and reading the code to try to
> guess where the reference is leaked / stored / ..., and then breaking
> on any function that returns the reference as result, etc?

you could override the acquire()/relese() methods on the service
implementation class and set breakpoints there.  but that may get
frustrating if it's passed around a lot... i guess tools like valgrind
can only tell you if it's leaked, not what continues to hold on to it.

> My end goal is to see if I cannot rather close the putative reference
> leak or break the putative cycle, so that the DatabaseContext is
> disposed as soon as it is not used anymore.