Mathias Bauer wrote:
Martin Gallwey wrote:
In the second stack I sent yesterday, for the finalizer thread, the top
of the stack is:
sw680mi.dll!SwXTextDocument::setPropertyValue(const rtl::OUString &
rPropertyName={...}, const com::sun::star::uno::Any & aValue={...})
Line 1944 + 0x27 C++
Which is:
void SwXTextDocument::setPropertyValue(const OUString& rPropertyName,
const Any& aValue)
throw( UnknownPropertyException, PropertyVetoException,
IllegalArgumentException,
WrappedTargetException,
RuntimeException)
{
::vos::OGuard aGuard(Application::GetSolarMutex());
Ie, it is blocked waiting for the SolarMutex. The dispatch thread locked
the SolarMutex long ago at SwXMLExport::exportDoc. So, essentially the
JVM garbage collection can't complete until the SwXMLExport::exportDoc
returns, which explains why it runs out of memory (causing
java.lang.OutOfMemoryError -> jni_uno::BridgeRuntimeError -> heap
corruption)- there is no garbage collection going on.
But why does that method not return? The waiting Finalizer thread alone
shouldn't be a problem because it isn't guaranteed even to work at any
particular time, so it can't also be a problem when it finishes.
From the stacks in one of Martin's postings, it looks like
SwXMLExport::exportDoc does a lot of computation (with the SolarMutex
acquired all the time, he sais), involving calls across the JNI--UNO
bridge. If those computations/JNI--UNO bridge calls need enough JVM
memory, and the (typically single-threaded!) JVM finalizer is blocked
(as it is from the stacks), the JVM can run out of memory, which in turn
can manifest in an OutOfMemoryError in the thread doing
SwXMLExport::exportDoc.
It would seem to me that locking the SolarMutex in the destructor of
XMLRedlineImportHelper is the cause of this problem - maybe we can find
a different solution for that doesn't involve setting properties back to
SwXTextDocument?
The destruction of the object *must* be guarded by the SolarMutex or
otherwise you would run into the problem Kay mentioned (possibility of
crashes because of race conditions). So we have to keep it (moreover: we
miss it on several other places as K&K showed in their report!).
Do I understand correctly that you think that the blocked finalizer
thread leads to an out of memory condition? Then in my understanding
there is no hope because whatever solution we choose the garbage
collection never will happen while any other API call is processed
inside the OOo process.
Not in the general case, but only if the involved API call can stall the
involved dtor as in Martin's case. Which is bad design, btw...
An approach that might help is if release-calls across the JNI--UNO
bridge (and across other bridges like URP bridges) were done
asynchronously, so that the JVM finalizer thread would not be blocked.
-Stephan
@Kay: Is that correct?
Best regards,
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
