Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
On 09/10/2013 06:40 PM, Lionel Elie Mamane wrote: On Mon, Sep 09, 2013 at 03:35:22PM +0200, Stephan Bergmann wrote: But wouldn't every "database context" be tied to some open window, I don't see why that would be That's why I phrased my sentence as a question---or at least tried to. 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). First, note that we don't have reference-counting garbage collection in general in UNO. For example, Java-UNO doesn't use reference-counting. Second, note that there needs to be code (the "owner" in the jargon of the udkapi/com/sun/star/lang/XComponent.idl documentation) that explicitly calls dispose on a UNO object. It is not magically called when a UNO object becomes unreachable. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
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
Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
On Mon, Sep 09, 2013 at 03:35:22PM +0200, Stephan Bergmann wrote:
> On 09/07/2013 09:46 AM, Lionel Elie Mamane wrote:
>> On Tue, Aug 20, 2013 at 10:57:06AM +0200, Stephan Bergmann wrote:
>>> On 08/16/2013 03:46 PM, Lionel Elie Mamane wrote:
On Fri, Aug 16, 2013 at 02:55:35PM +0200, Stephan Bergmann wrote:
> No real insight into any of this, but would it make sense to rely on
> some explicit "commit" stimulus to do that committing, instead of
> doing it upon "dispose"
I don't understand what "commit stimulus" is.
>>> I was thinking of some "close" function (analogous to how, say, a
>>> Java class representing a file should have an explicit close()
>>> method rather than relying on a finalizer).
>> It seems the shutdown of ODatabaseContext at "dispose" time creates
>> other problems... E.g. https://bugs.freedesktop.org/69036
>> So I tried to look into this, and using a "close" that would be called
>> earlier makes sense to me, but in the context of application shutdown,
>> I don't see *who* would call it when :-| I'm a bit stuck there.
> But wouldn't every "database context" be tied to some open window,
I don't see why that would be, unless we create a "fake" window in
headless situations or for things that don't have a UI window. I'm
thinking of this scenario:
1) run
soffice "-accept=socket,host=localhost,port=2002;urp;"
or
soffice "-accept=socket,host=localhost,port=2002;urp;" --nodefault
or
soffice "-accept=socket,host=localhost,port=2002;urp;" --headless
or
soffice "-accept=socket,host=localhost,port=2002;urp;" --headless --nodefault
or some such.
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?
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).
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?
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.
I grepped through some code creating DatabaseContext, it seems to
usually hold the reference for only a *short* time.
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
On 09/07/2013 09:46 AM, Lionel Elie Mamane wrote: On Tue, Aug 20, 2013 at 10:57:06AM +0200, Stephan Bergmann wrote: On 08/16/2013 03:46 PM, Lionel Elie Mamane wrote: On Fri, Aug 16, 2013 at 02:55:35PM +0200, Stephan Bergmann wrote: No real insight into any of this, but would it make sense to rely on some explicit "commit" stimulus to do that committing, instead of doing it upon "dispose" I don't understand what "commit stimulus" is. I was thinking of some "close" function (analogous to how, say, a Java class representing a file should have an explicit close() method rather than relying on a finalizer). It seems the shutdown of ODatabaseContext at "dispose" time creates other problems... E.g. https://bugs.freedesktop.org/69036 So I tried to look into this, and using a "close" that would be called earlier makes sense to me, but in the context of application shutdown, I don't see *who* would call it when :-| I'm a bit stuck there. But wouldn't every "database context" be tied to some open window, or some "shell" in sfx2 speak, or somesuch, and could thus be closed when the latter is closed (which presumably happens before the UNO service manager is shut down)? Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
On Tue, Aug 20, 2013 at 10:57:06AM +0200, Stephan Bergmann wrote: > On 08/16/2013 03:46 PM, Lionel Elie Mamane wrote: >> On Fri, Aug 16, 2013 at 02:55:35PM +0200, Stephan Bergmann wrote: >>> No real insight into any of this, but would it make sense to rely on >>> some explicit "commit" stimulus to do that committing, instead of >>> doing it upon "dispose" >> I don't understand what "commit stimulus" is. > I was thinking of some "close" function (analogous to how, say, a > Java class representing a file should have an explicit close() > method rather than relying on a finalizer). It seems the shutdown of ODatabaseContext at "dispose" time creates other problems... E.g. https://bugs.freedesktop.org/69036 So I tried to look into this, and using a "close" that would be called earlier makes sense to me, but in the context of application shutdown, I don't see *who* would call it when :-| I'm a bit stuck there. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: dbaccess::ODatabaseContext cleaning its cache "too late"?
On 08/16/2013 03:46 PM, Lionel Elie Mamane wrote: On Fri, Aug 16, 2013 at 02:55:35PM +0200, Stephan Bergmann wrote: No real insight into any of this, but would it make sense to rely on some explicit "commit" stimulus to do that committing, instead of doing it upon "dispose" I don't understand what "commit stimulus" is. I was thinking of some "close" function (analogous to how, say, a Java class representing a file should have an explicit close() method rather than relying on a finalizer). (or at least take into account m_bModified and not try to commit if not necessary?). This seems to make sense; embedded hsqldb are a bit weird because they save some files (the ones in database/) "automatically" even without user "save" action. I *hope* that this does not clobber m_bModified if *other* changes are pending (e.g. creation / modification of a report / form / ...). I wouldn't be *too* surprised if the "save even when m_bModified == false" was to work around a putative "m_bModified is clobbered wrongly" issue. (Just to make it clear: I don't plan to follow up on this with any patches; just wanted to bring it up.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
