https://bugs.freedesktop.org/show_bug.cgi?id=65882

--- Comment #1 from Michael Meeks <[email protected]> ---
<mmeeks> sberg: _rene_'s AMD64 bug looks like a random ordering artefact
<mmeeks> sberg: as we shutdown the remote UNO acceptor it -looks- (to me) as if
we iterate over the map of live references and just unref them - is that so ?
<mmeeks> sberg: [ and if so, I guess changes in the order of that map may
randomly affect behaviour ? ]
<sberg> mmeeks, yes, when we dispose a bridge we call release on all the local
objects still bridged out over that bridge (which e.g. happens when the remote
end is Java and hasn't yet GC'ed the proxy)
<sberg> mmeeks, but that itself should not cause any problems
<mmeeks> sberg: well - some objects have to be destroyed in a certain order.
<mmeeks> sberg: if you see that trace, the Redline import thing must be
destroyed before the Document that it is working on
<mmeeks> otherwise exceptions get fired.
<sberg> mmeeks, some objects need to be destroyed in a certain order for sure;
but note that calling release on an object does not necessarily destroy it
<mmeeks> which seems to be the cause of the test failures Rene is seeing - I
guess some difference in the JavaVM around garbage collection timing, and/or
some change in order in the map.
<mmeeks> true;
<mmeeks> so in fact I mean that SwXDocument must be 'Invalidate'd in the right
order vs. the destroy of the redline reference.
<mmeeks> sberg: advice appreciated, we could a) just ignore such exceptions
during the filter shutdown
<mmeeks> sberg: or b) tweak the Java code to try to explicitly free / unref the
remote reference [ is that even possible ]
<mmeeks> sberg: c) another other option ;-)
<sberg> mmeeks, the root problem is probably that ~XMLRedlineImprotHelper wants
to do some activity, and assumes that it is called at a specific time
<sberg> mmeeks, (this has historically been a source of lots of trouble, dtors
of UNO objects doing stuff and then being called at unpredictable times from
Java GC; most such problems should be solved by now)
<sberg> mmeeks, so I guess what's immediately needed here is that
~XMLRedlineImportHelper cope with its SwXTextDocument already being invalidated
(i.e., catch the relevant exceptions)
<mmeeks> sberg: fair cop - will add some magic there, and OSL_WARN if it fires
tec.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to