|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Bugdoc leads to crash by endless recursion in Basic | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Writer | Reporter: | jensberke <info> | ||||
| Component: | ui | Assignee: | ab | ||||
| Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||
| Severity: | Trivial | ||||||
| Priority: | P2 | CC: | issues | ||||
| Version: | OOo 1.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
jensberke
2003-10-28 20:23:11 UTC
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. |