Hi Michael,
>> Since we started using LibreOffice versions later than 3.5 (I think),
>> we have seemingly random problems with LibreOffice freezing when
>> opening an embedded Visio object.
> Ok - do you have a stack-trace ? if you run 4.2 of course you can get
> debugging symbols for that which would make the problem debuggable at least -
> a deadlock is a beast that gives a nice stack trace (if you get all threads).
Michael Stahl pointed me to winDbg and Kendy's wiki; currently we are
trying to reproduce the problem and produce a stack-trace. When we succeed, I
will create a bug report with it and cc you and Michael Stahl.
>> Today, I had a breakthrough: a colleague reported that he received an
>> error message, "Algemene OLE fout". Normally, we don't get that,
>> LibreOffice just freezes.
>> This string and opengrok led to ERRCODE_SO_GENERALERROR belonging to
>> the string, /core/sfx2/source/view/ipclient.cxx, which is the only file
>> where ERRCODE_SO_GENERALERROR is used.
> How do you get from there to here:
>> This led to a TODO-comment in
>> /core/embeddedobj/source/commonembedding/embobj.cxx,
>> OCommonEmbeddedObject::doVerb( ... ):
The try statements above the catch where the error code is used all
have a call to doVerb(). It is a bit of an educated guess.
>> I know that the SolarMutex issue is getting attention, and that area
>> is far beyond my capabilities.
> I rather suspect that the SolarMutex is not the problem in itself; but the
> non-Solar mutex :-) Solar Mutex locking is relatively tractable and
> comprehensible. The problem mostly comes when people try to be too clever and
> use another mutex: which is a recipe for deadlocks.
The more reason for me to try to keep away from mutexes. Which will
have a catch, of course =)
Winfried
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
