Apache OpenOffice (AOO) Bugzilla – Issue 904
Inserting ole2 objects in writer into a frame of different size from object's native size causes assert
Last modified: 2003-09-08 16:56:16 UTC
In Writer Insert->Object->OLE Object...->Further Objects-> Choose MS Equation Editor, input some text and close Get "Error: SolarMutex not locked in the Main thread." * 10 This error dialog occurs for Writer, it might be a problem in so or vcl ?, but it doesn't happen in Impress. It appears to happen when the graphic representation of the ole2 object is inserted into a drawing location that is of a different size from the object's native size. It is occuring with all equation editor objects. Also for example insert a microsoft graph chart object, resize the default graphic shown in the chart application ole2 helper application and "update". The "mutex lock" error occurs many times, mostly from two locations, one as follows... with the other trace at the end. Insert the chart without resizing in the helper application and there is no such assert. I've seen this error in the past, and I think it has been fixed before, but it never seems to stay fixed for long. This error is seen in at least 618 630 & 631 TL631MI! DbgOut(char const *,unsigned short,char const *,unsigned short) + 830 bytes VCL631MI! ImplDbgTestSolarMutex(void) + 242 bytes TL631MI! DbgFunc(unsigned short,void *) + 372 bytes VCL631MI! OutputDevice::ImplGetGraphics(void) + 18 bytes VCL631MI! OutputDevice::ImplDrawColorWallpaper(long,long,long,long,class Wallpaper const &) + 26 bytes VCL631MI! OutputDevice::ImplDrawWallpaper(long,long,long,long,class Wallpaper const &) + 143 bytes VCL631MI! OutputDevice::Erase(void) + 174 bytes VCL631MI! Window::ImplCallPaint(class Region const *,unsigned short) + 882 bytes VCL631MI! Window::Update(void) + 795 bytes SW631MI! ViewShell::ImplEndAction(unsigned char) + 413 bytes SW631MI! SwFEShell::IsOf(void * (*)(void)) + 22 bytes SW631MI! SwFEShell::IsA(void * (*)(void)) + 10 bytes SW631MI! SwEditShell::EndAllAction(void) + 33 bytes SW631MI! SwOleClient::ViewChanged(unsigned short) + 451 bytes SO631MI! SvAdvise::SendViewChanged(void) + 196 bytes RPCRT4! 77da1586() RPCRT4! 77da27c0() OLE32! 77b29179() OLE32! 77b29ea2() OLE32! 77a81687() OLE32! 77a815cc() OLE32! 77a81f14() OLE32! 77b29db2() OLE32! 77b29b97() OLE32! 77b2a14b() OLE32! 77a81d20() USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e13f0f() VCL631MI! ImplSalYield(unsigned char) + 171 bytes VCL631MI! ImplSalYield(unsigned char) + 59 bytes VCL631MI! SalInstance::Yield(unsigned char) + 192 bytes VCL631MI! Application::Yield(void) + 77 bytes VCL631MI! Application::Execute(void) + 47 bytes SFX631MI! SfxApplicationClass::Main(void) + 2991 bytes SOFFICE! Desktop::Main(void) + 1335 bytes VCL631MI! SVMain(void) + 188 bytes The second trace is TL631MI! DbgFunc(unsigned short,void *) + 325 bytes VCL631MI! DbgPrintMsgBox(char const *) + 422 bytes TL631MI! DbgOut(char const *,unsigned short,char const *,unsigned short) + 830 bytes VCL631MI! ImplDbgTestSolarMutex(void) + 242 bytes TL631MI! DbgFunc(unsigned short,void *) + 372 bytes VCL631MI! OutputDevice::ImplSetClipRegion(class Region const *) + 39 bytes VCL631MI! OutputDevice::SetClipRegion(class Region const &) + 327 bytes SO631MI! SvEmbeddedObject::DoDraw(class OutputDevice *,class Point const &,class Fraction const &,class Fraction const &,class JobSetup const &,unsigned short) + 657 bytes SO631MI! SvEmbeddedObject::DoDraw(class OutputDevice *,class Point const &,class Size const &,class JobSetup const &,unsigned short) + 473 bytes SW631MI! SwNoTxtFrm::PaintPicture(class OutputDevice *,class SwRect const &,class SwRect const &) + 1433 bytes VCL631MI! 221ae27a()
this looks like a problem of the SvAdvise::SendViewChanged handler.
It is a known problem, we have to lock VCL mutex and do some tricky marshalling stuff.
Work is in progress.
changing QA contact from bugs@ to issues@
TRA->JL: Is this still an issue after your reanimation of the so3 project?
JL->TRA: so3 has not been reanimated (as you put it) it is still being used. JL->CMC: I could not reproduce this bug with an 642 on Windows XP and Office 2000. I remember that I fixed a bug like that months ago. Probably that was it.
Indeed, it does appear to have gone away.
close