Issue 59550 - [API] accessing a introspection adapter after releasing the XIntrospectionAccess crashes OOo
Summary: [API] accessing a introspection adapter after releasing the XIntrospectionAcc...
Status: ACCEPTED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 680m142
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-19 12:45 UTC by Frank Schönheit
Modified: 2017-05-20 11:31 UTC (History)
1 user (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 Frank Schönheit 2005-12-19 12:45:14 UTC
execute the following piece of C++ code (I am sure that this is reproducible in
Java, too, but the C++ example was easier for me to create :)

  // create the desktop component
  Reference< XInterface > xDesktop = _rxFactory->createInstance(
    ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
      "com.sun.star.frame.Desktop" ) ) );
  // create an instrospection component
  Reference< XIntrospection > xIntrospection( _rxFactory->createInstance(
    ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
      "com.sun.star.beans.Introspection" ) ) ), UNO_QUERY );
  // let it inspect the desktop
  Reference< XIntrospectionAccess > xIntrospectionAccess(
    xIntrospection->inspect( makeAny( xDesktop ) ) );

  // query an XPropertySet adapter
  Reference< XPropertySet > xPropertyAccess(
    xIntrospectionAccess->queryAdapter( XPropertySet::static_type() ),
    UNO_QUERY );

  // ask for some arbitrary property
  Any aValue = xPropertyAccess->getPropertyValue(
    ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "IsPlugged" ) ) );

  // now release the introspection access, and ask again for the same property
  xIntrospectionAccess.clear();
  aValue = xPropertyAccess->getPropertyValue(
    ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "IsPlugged" ) ) );

=> GPF

Targeting this to 2.0.2 since it's a crash which can be easily reproduce when
scripting OOo
Comment 1 Frank Schönheit 2005-12-19 12:49:28 UTC
fs->ab: The problem seems to be that the ImplIntrospectionAdapter (which is the
instance implementing the adapter returned by queryAdapter) holds a reference to
an Any which is owned by the ImplIntrospectionAccess instance.

When the latter is destroyed (which happens automatically when
xIntrospectionAccess is cleared in the above example),
ImplIntrospectionAdapter::mrInspectedObject refers to a already-deleted object
then, and thus crashes upon access.

I think that ImplIntrospectionAdapter should hold alive its
ImplIntrospectionAccess instance - as long as the former lives, the latter
should live, too. However, this would have the disadvantage of a cyclic
reference, since ImplIntrospectionAccess also holds a reference to the
ImplIntrospectionAdapter.
Probably the reference from the Access to the Adapter should be made weak ....
Comment 2 ab 2005-12-20 09:11:55 UTC
ab->fs: I'm not sure if I understand your reason for setting this task to 2.0.2.
IIRC typical PP candidates are regression tasks or crashes that can be
reproduced by just using the office. But this bug must have been there since
inventing the introspection, not later then for SO 6 I guess. Besides this you
have to write C++ code to reproduce it. You can get as many crashes as
you want by writing C++ code even without using introspection... ;-) 

And where's the connection to "scripting OOo"? Ok, you could script it with
Java using the scripting framework, but first I doubt that this is widely used
compared to Basic and second even then using the introspection service
from Java used as scripting language is not very likely. So it may be easy
to reproduce, but only if you target for it. You're the first who found this bug
in years, so in my opinion targetting it to OOo 3.0 really should be enough.
Is this ok for you?
Comment 3 Frank Schönheit 2005-12-20 11:15:15 UTC
As said, I could most probably write the same piece of code in Java, provoking
the crash. I cannot judge how likely it is that somebody encounters this in
Java, so looking from this side, I don't have an opinion on the target.

However, given that stability is *the* goal for 2.0.2, and that we here have a
reproducible and easy-to-fix (IMO) crash, I still think that 2.0.2 isn't a bad
target ...
Comment 4 Frank Schönheit 2005-12-20 11:28:19 UTC
Is making mrInspectedObject an "Any" instead of an "const Any&" an option? This
also fixes the problem, but I am uncertain whether there are performance
penalties associated with this approach.
Comment 5 ab 2005-12-22 10:13:43 UTC
I will have a look. If I can fix this without any risk, I will do it for 2.0.2.
Otherwise the possibility that someone could write a Java macro
that leads to just this scenario seems a little bit too vague for me.
Comment 6 ab 2006-01-26 15:13:02 UTC
I've analysed this but I don't feel comfortable about fixing this for pp2
as I think a fix won't be very complex but also not trivial and the code 
that would have to be changed provides the core functionality for the
Basic-UNO binding. I still doubt that this problem is severe enough
for risking anything -> OOo 3.0
Comment 7 kai.sommerfeld 2006-06-15 15:03:59 UTC
.
Comment 8 ab 2006-08-18 12:23:53 UTC
-> OOo later
Comment 9 moctecheckva 2010-11-10 16:42:09 UTC
Created attachment 73262
Comment 10 Marcus 2017-05-20 11:31:18 UTC
Reset assigne to the default "issues@openoffice.apache.org".