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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice