Apache OpenOffice (AOO) Bugzilla – Issue 21837
Bugdoc leads to crash by endless recursion in Basic
Last modified: 2013-08-07 14:41:36 UTC
I created a Writer document with OpenOffice.org 1.0 some time ago (on Win 2000) which contains a small macro I've written. After opening the file and deleting the macro on Linux (Suse 8.2) with OpenOffice.org 1.1.0 (German), OOo crashes when opening the document. Steps to reproduce: Download the attached zip-file. It contains 2 Writer documents Open "macrotest_working.sxw" and let the makro execute. Should show a window saying "Hello" go to Menu "Extras -> Macros -> Macro..." go to macroname "macrotest_working.Standard.Main" select 1st macro "main", press delete and confirm with "yes" delete the other 3 macros the same way as the 1st one save document and close OOo reopen the document =>here's the bug: OOo will start, load the document and exit immediately. No error shows up, it just vanishes. I cannot open and edit the document anymore! macrotest_broken.sxw is the file that resulted on my PC from doing the steps above. I tested this on Win2000. No problem there.
Created attachment 10724 [details] Two Writer documents with macros that show how this defect occurs
One more thing to the steps to reproduce this defect: When reopening the document after the macros have been deleted and the document been saved, OOo asks me if I allow macros to be executed. Mmh, I just deleted all macros, how come there are still macros in there? Anyway. Only if I click "Execute" (German: "Ausführen"), the described error occurs. When clickung "Don't execute", the document opens without problems.
Jens, thank you for taking the time to submit this bug. Verified on RH 9.0, OOo 1.1.0.
Reassigned to JSK
JSK->TBE: I feel like i have heard this before. A document that contained macros will never really forget that they were there. There was not much we could do about that. IIRC this was caused by the way we handle macros ... TBE: Any comments?
It is true. In 1.1.0, if I open a document that once had a macro (and I deleted it), while it doesn't crash, it does insist on asking if I want the macro running. I always answer "yes" and let it run the non-existent macro. I would love to have this "feature" removed from OOo as it's a real pain somewhere.
Corrected platform, os, priority, target. Even if title is misleading, i'll keep it. This one should be resolved for OOo 2.0, no chance for 1.1.1 / 1.1.2
The 'Run Macro' dialog shows up and asks you, if you want to run macros, if the document contains any Basic modules. If you delete all macros in the 'Macro' dialog, then there remains a Basic module, e.g. Module1. If you delete all modules in the 'Macro Organizer' dialog, then no module remains and the next time you open the document the 'Run Macro' dialog doesn't show up.
The problem is that we check for the existence of BASIC while loading a document. If BASIC is found, the macro execution-dialog will be displayed. The only way to avoid the dialog is to delete all documentbound BASIC. This is done by deleting the BASIC Module, not just the macros contained therein. Suggestion is: When deleting BASIC from a document, the deletion of the last macro should trigger a dialog asking the user if the module should be deleted as well. MBA supports the idea, this is a minor effort task. We need a spec for that. It might fit under the PCD topic for speeding up the application startup (indirectly because it avoids the interruption of the load-process and the routines for handling BASIC won't have to be loaded). Note: If there has ever been a crash related to loading of empty BASIC code, the suggested procedure will fix it as well. Changed Summary, set enhancement, changed owner to bh, removed keywords.
accepted
TBE->AB: The crash is a stack overflow caused by an endless recursion of SbxObject::Find() and StarBASIC::Find().
TBE->JSK: Please write a separate feature task with target OO.o Later for asking to delete the module, if the last macro is deleted, and send that to BH for evaluation. The crash should be handled in this task (please set priority to P2).
jsk->tbe: I have created a new feature task (issue 32424) that covers the dialog to ask the user whether he likes to delete the module along with the last macro. Owner bh, target is OOo Later. For this task: change prio -> P2 change type -> defect change owner -> as jsk->as: Can you please change the subject to something meaningful?
Sorry, this task was not for as but for ab. :(
cp->ab: please change the title to something that matches better to the content.
Accepted
Fixed
can't create the document from _working that way in src680m50, but can reproduce with the attached _broken. verified in CWS on linux
works.