Apache OpenOffice (AOO) Bugzilla – Issue 14041
Crash when close generated Draw document while Macro still running
Last modified: 2004-04-21 16:11:22 UTC
Here is a Draw document that reproduces the bug. http://kosh.datateamsys.com/~danny/OOo/BugAttachment/ColorWheel-20030502-4.sxd Open the draw doc. Click the button "Start Bouncing Ball". A new drawing appears, with a bouncing ball. (The ball will only bounce for 30 seconds, and is then programmed to time out.) Before the 30 second timeout, close the new drawing with the animated bouncing ball. OOo 1.1-beta crashes on Win XP. Closing the new auto-generated drawing, while a macro is still trying to manipulate objects on that drawing is likely the underlying cause. Closing the drawing should at least cause the macro to get a runtime error. Even better would be if there were some capability such that the Macro could be written to detect the problem and react gracefully.
Created attachment 6013 [details] Draw document with macro that exhibits bug OOo1-1beta WinXP
Andreas, I can reproduce this also on Linux. Please take a look at it.
Changed to P2 because of crash. In this situation Basic just accesses an object that is already dead (although Basic holds a reference to it!). I have no idea how Basic should avoid this because Basic is not notified that the document it belongs to and is working on is closed. ->MBA: I think a document with a running Basic must not be closed. You told me that Basic cannot be ask if a document's Basic is currently running. That's right, but it would be / have been easy to implement a corresponding method. I simply did not know that is was needed. In any case I see no way to fix this in Basic. Do you have any other idea?
Closing views is now prevented if any macro is running Fixed in CWS fwk02
Forgot to set the right target :-)
@tm: Please verify
TM: Checked and verified in cws fwk02 -> OK !
.
Atr: also fixed in current version.
We discussed the problem again and came to the conclusion that the provided fix is not acceptable. It is not okay to disable closing of any documents as long as StarBasic is active. This simply breaks senseful functionality. The document that cannot be closed might be completely unrelated to the running StarBasic. We need a real fix in the drawing application here. Reopening issue.
Submitted #i18622# for removal of original fix (target: OOo 1.1.1). Reassigning task to drawing team. Resetting target milestone.
The office crashes in SdGenericDrawPage::getPropertyValue(). The problem is, that the SdGenericDrawPage is a UNO component, which is not disposed yet, but the internal C++ structure is already destroyed, especially the pPage member of the SvxDrawPage in this case. When the document is closed, the C++ drawing view and the C++ drawing model are destroyed. But the running StarBasic still has a reference to the UNO component which represents the document. Therefore the UNO document component should be destroyed only after the last UNO reference to it has been released. It seems that the internal C++ reference counting and the UNO reference counting differ. A C++ drawing model may have several C++ drawing views. After the last C++ drawing view is destroyed, the C++ drawing model is destroyed. It seems that the UNO reference counting is neglected at all. In summary, this bug should be fixed in that way, that the UNO document component and consequently all its internal C++ structures are only destroyed after the last reference is released. One can also think about disposing the UNO wrappers in the drawing view/model destructors. If then StarBasic calls an API method of a disposed UNO component, a DisposedException is thrown which will be handled by StarBasic. This probably fixes the crash, but the problem with the wrong UNO reference counting remains. For Geordi PP1 the following scenario seems to be the right way. The initial fix for this task will be removed. This allows, that a document can be closed via UI, even if StarBasic is running. The crash can be avoided, if the StarBasic programmer implements an event listener which will be registered at the document component. When the document is closed, the listener will be notified and StarBasic can be stopped with the 'Stop' command. See a code example below. Sub BouncingBall() ... ' Create a new Draw document Dim oDrawDoc As Object oDrawDoc = MakeNewDrawDoc() ' Add an event listener Dim oListener oListener = CreateUnoListener( "DrawDocListener_", "com.sun.star.lang.XEventListener" ) oDrawDoc.addEventListener( oListener ) ' Bounce the ball ... ' Remove the event listener oDrawDoc.removeEventListener( oListener ) End Sub Sub DrawDocListener_disposing( oEvent ) ' Stop the execution of the running StarBasic Stop End Sub
AW->CL: This needs to be implemented in the UNO API.
Kay reproduced it, so it's confirmed...
I will recheck the sd API that it handles destroyed core implementations correctly
Draw and Impress now throw DisposedException when api calls are made to components that are disposed
somehow the buttons from the testfile do not work in a current release, but you can start the bouncing ball macro for testing by hand
SW->CL: as seen the crash still occurs in cws_impress5ea1
The original crash was fixed, the resulting crash caused by another fix in this cws that only happens if accessibility support is on. this is now fixed
SW: fixed in cws_impress5ea1
SW: works as expected in cws_impress5ea1 => verified
SW: ok in src680_m35 => closed