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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice