To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=73457
------- Additional comments from [EMAIL PROTECTED] Sun Jan 28 13:24:24 -0800
2007 -------
If A is a subroutine, then the method call A(0) generates the Pcode statements
FIND A, Empty, Args
GET
The StepFIND(“A”, Empty!Args) instruction call invokes SbInstance::FindElement
which after a lot of cascade logic ends up the code branch which processes
Methods. This invokes the following statement to make the call:
SbxVariable* pNew = new SbxMethod( *((SbxMethod*)pElem) );
which cascades through the copy constructor for SbxVariable, after calling the
copy constructors for the superclass SbxValue and the properties pPar and pInfo,
this goes branch depending on where the value is readable (which it isn’t for a
method call) and then issues a Broadcast(SBX_HINT_DATAWANTED). Broadcast is a
virtual method on since this variable is a SbMethod, SbMethod::Broadcast is
invoked. It is this Broadcast that is ultimately invokes the Run method which
executes the method.
This call cascade generates the class property SbxArray refArgv created in
StepARGC() to hold the Argument Stack, the SbxVariable p created in LOADI() to
hold the constant 0 used as the parameter, and the copy constructor for SbMethod
creates a new SbMethod in. In a normal function call all three of these
variables are ultimately destroyed and garbage collected in the various exit
sequences as the routine unroll through the call stack. The first to go is the
SbxArray that was referenced by refArgv. The StepPARAM() routine fetches the
parameter with a p = refParams->Get( 0 ) and skips some processing handling
SbxERROR and coercion of types, falling though to SetupArgs(p, nOp1) which does
a p->SetParameters (NULL) if it is not a ByVal. This in turn does a
SbxArrayRef::operator= assignment to NULL, which dereferences the previous
contents and this triggers the SvRefBase garbage collection process of the now
zero reference SbxArray. The SbMethod is destroyed later in SbMethod::Broadcast
by the assignment pCst = NULL which invokes the SbMethod:: operator= which
dereferences the underlying SbMethod, and finally the SbxVariable is referenced
and deleted in pushing the return value.
However all of this logic is built on the assumption that the method actually
returns a value. In the case of a standard Sub call, the method type is SbxVOID
so this assumption is flawed. The logic flow that is folloed in this case
short-circuits code paths that dereference the values. I’ve verified this by not
setting the return value on a function call and force a return on a subroutine
call.
The challenge is no longer understanding why the leak occurs but more what is
the appropriate fix to remove it. My problem is that this whole code area seems
to have fix-ups upon fix-ups. I’ve done this in my test harness to validate the
diagnosis, but I don’t really want to propose another botch. Need to think
about this one a bit more.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
