Post to dev-QA by Martin Blapp mb@imp.ch

Hi,

Yes I can confirm this bug and it is still not solved. Any ideas are
welcome.

Since the same code does work on MacOSx and Linux, it may have its
cause in the rtld, where probably a thrown exception is not
catched. There are three different throwers in the function where
it does crash.

Here is a crashdump:

#0  0x28158238 in SfxItemPropertyMap::GetByName(SfxItemPropertyMap const*,
rtl::OUString const&) () from
/usr/local/OpenOffice.org1.0/program//libsvl641fi.so
#1  0x30eadb79 in SwXShape::getPropertyValue(rtl::OUString const&)
(this=0xbfbfe280,
    rPropertyName=@0x28079241)
    at oo_1.0.2_src/sw/source/core/unocore/unodraw.cxx:1150
#2  0x2ed29d25 in needLogicRectHack(SdrObject*) (pObj=0x323929e0)
    at oo_1.0.2_src/svx/source/unodraw/unoshape.cxx:1068
#3  0x2ed29d9a in getLogicRectHack(SdrObject*) (pObj=0x323929e0)
    at oo_1.0.2_src/svx/source/unodraw/unoshape.cxx:1096
#4  0x2ed2a309 in SvxShape::getSize() (this=0xbfbfe494)
    at oo_1.0.2_src/svx/source/unodraw/unoshape.cxx:1181
#5  0x2ed484de in SvxShapeControl::getSize() (this=0xbfbfe490)
    at oo_1.0.2_src/svx/source/unodraw/unoshap2.cxx:672
#6  0x304ccd71 in Lcopy () from
/usr/local/OpenOffice.org1.0/program//libgcc3_uno.so
#7  0x304cd0f0 in gcc3::cpp_call(gcc3::cppu_unoInterfaceProxy*, long,
_typelib_TypeDescriptionReference*, long, _typelib_MethodParameter*,
void*,
void**, _uno_Any**) ()
   from /usr/local/OpenOffice.org1.0/program//libgcc3_uno.so
#8  0x304cd521 in gcc3::cppu_unoInterfaceProxy_dispatch(_uno_Interface*,
_typelib_TypeDescription const*, void*, void**, _uno_Any**) ()
   from /usr/local/OpenOffice.org1.0/program//libgcc3_uno.so
#9  0x31bcee9e in
stoc_corefl::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any
const&

Any help is welcome

Martin

mh->fs,os : can you comment on this, please ?

This looks like a build problem. 
The stack is ok up to #2 needLogicRectHack() but it's wrong in calling
SwXShape::getPropertyValue() which is not called here. 
See svx/source/unodraw/unoshape.cxx

mh->mbr: does this still occur ?

Yes still happens. And it happens with OO1.1Beta too.

mh->mbr: as agreed retargeted to 1.0.4

mh->mbr: as agreed retargeted to 1.0.4

Hello, 

I found that this Issue is targetted to 1.0.4. 
Can you please retargetting this issue since 1.0.4 is not planned.
maybe to 1.1.1 ? 

Thanks

nope. Since the bug does not occur in an 1.1 build (which is most
likely, since people are talking about a build problem), it's not
necessary to do anything, unless we really create a 1.0.4.

This is most likely _NOT_ a build problem.  The same code is present in two different libraries, with the 
same routine names.  Comments in the code state that it was specifically copied from one library to the 
other.  Can we _please_ make this stuff static from now on?  Sheesh.  Therefore, with this in mind (see 
the EntryList_Impl problems, Issue 17727), we need to either make these static, namespace them, or 
make them part of a class, so that dynamic linkers actually _know_ which symbol to resolve stuff to...

Created attachment 13303 [details]
prefix disputed symbol with sch_

Created attachment 13304 [details]
prefix disputed symbol with svx_

-> PATCH, retarget to 1.1.2

fa, I suggest prefixing the symbols with "lcl_". This should prevent them from
being exported (every module should have mechanisms for filtering out symbols
containing "lcl_"). Alternatively, an unnamed namespace sounds like a good idea.

Hi Frank,

I have no idea why a 'lcl_' prefix should help in any way. There is no such
'magic' as automatic filtering (except maybe on Windows).

The only 'magic' that works on any platform and with any compiler is the
'static' keyword. So the correct solution / patch would be (e.g.)

-sal_Bool needLogicRectHack( SdrObject* pObj )
+static sal_Bool needLogicRectHack( SdrObject* pObj )

Anything else is completely unnecessary, and not transparent to anyone looking
at the code.

Matthias

Created attachment 13316 [details]
Updated sch patch, add "static" before functions in question

Created attachment 13317 [details]
Updated svx patch, add "static" before functions in question

Please approve for commit to cws_src680_ooo20040225.

mhu: If you'd like me to remove the "sch_" and "svx_" prefixes before the functions, I will do that before 
commit.

Also please approve for commit to next 1.1.2 branch, whenever that opens.

Hi Dan,

Well, if you could also adapt your comment (i.e., that those functions need to be
declared 'static') you could choose any prefix you like (as it doesn't matter :-) ).

Otherwise, the patches are approved for both OOo 2.0 and OOo 1.1.x

Matthias

committed to cws_src680_ooo20040225

Set resolution to fixed.

Verified.

Ah, I overlooked that this issue is for OOo-1.1.2, too. Reopened.

Since FreeBSD is having problems with this now and they can reproduce it reliably, this fix should 
probably go into 1.1.1.  If you don't agree with 1.1.1 target, please retarget to 1.1.2.

fa: On FreeBSD - it could also be caused by their ld.so bug. I do not think it
counts as reproduce reliably.

There is not enough time to test this properly before 1.1.1 and maho also
reported in Message-Id: <20040317.123854.424243887.chat95@mac.com> that this
patch does NOT helped him.

Retargeting to 1.1.2.

.

fa, and pavel,
pavel is right. it doesn't help me (5.2.1-RELEASE)
thanks

set target to 1.1.3

Since it doesn't help FreeBSD, closing as fixed since its already committed and
on MAIN 680.

close issue