|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | [API] accessing a introspection adapter after releasing the XIntrospectionAccess crashes OOo | ||
|---|---|---|---|
| Product: | udk | Reporter: | Frank Schönheit <frank.schoenheit> |
| Component: | code | Assignee: | AOO issues mailing list <issues> |
| Status: | ACCEPTED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues |
| Version: | 680m142 | ||
| Target Milestone: | AOO PleaseHelp | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
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 .... 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? 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 ... 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. 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. 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 . -> OOo later Created attachment 73262 Reset assigne to the default "issues@openoffice.apache.org". |
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