Issue 904 - Inserting ole2 objects in writer into a frame of different size from object's native size causes assert
Summary: Inserting ole2 objects in writer into a frame of different size from object's...
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 627
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: ---
Assignee: caolanm
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-05-16 10:19 UTC by caolanm
Modified: 2003-09-08 16:56 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2001-05-16 10:19:01 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()
Comment 1 jp 2001-05-17 15:08:29 UTC
this looks like a problem of the SvAdvise::SendViewChanged handler. 
Comment 2 Unknown 2001-05-18 06:18:31 UTC
It is a known problem, we have to lock VCL mutex and do some tricky marshalling
stuff.
Comment 3 tino.rachui 2001-06-05 11:23:33 UTC
Work is in progress.
Comment 4 Unknown 2001-11-08 23:11:36 UTC
changing QA contact from bugs@ to issues@
Comment 5 tino.rachui 2002-05-17 07:19:18 UTC
TRA->JL: Is this still an issue after your reanimation of the so3 project?
Comment 6 joachim.lingner 2002-05-22 10:52:16 UTC
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.
Comment 7 caolanm 2002-05-23 15:20:37 UTC
Indeed, it does appear to have gone away.
Comment 8 caolanm 2002-05-23 15:20:53 UTC
close