Apache OpenOffice (AOO) Bugzilla – Issue 74058
Closing Macro-editor crashes office.
Last modified: 2007-03-27 09:46:34 UTC
Tools - Macro - Organize Macros. Choose a macro. Click on "Edit". (and if one compares with for instance m2, then one already now notices how the macro is opening slowing on m5) But, if one now either clicks on "X" (in the upper right window-corner), or uses File - Exit, then the office, with all it's eventual instance, closes. As mentioned, this one is broken, seen ok in OOF_m2.
Confirmed. Note: I had to select one of the basic modules from the shared layer (OpenOffice.org Macros, like euro/common) and click edit. It takes a few seconds before the application actually crashes.
More specific instructions: 1. Open up Draw. 2. Tools - Macros - Organize Macros - StarOffice Basic. 3. StarOffice Macros - Euro - Common - Start Conversion. (Just mark the entry) 4. Press the "Edit" -Button. 5. File - Exit. - Results in a crash.
.
I can confirm both the slowdown when opening the macro for editing and the crash. The slowdown however, is not related to the crash. fredrikh, you should supply another task for the slowdown. #73858# will only deal with the crash.
kso, I see a connection between the slowdown and this issue. Because it's only when this "slowdown" has occured, as one can bring the office to crash. For instance - when choosing the very first macro in the organizer "Main" (in My Macros - standard - Module1), the editor neither takes long to load the file (next to instantly), nor can I reproduce this bug when it has. (which by the way gives you a hint about what causes the bug, because the file "Main" contains next to no code at all) Have in any case written another issue, ( i74065 ) just in case fixing this issue wouldnt correct the performance-issue.
kso->fs: The crash (as well as the slowdown when loading macros #74065#) is caused by your fix for #73412#. Please take over.
I want to emphasize that my fix for issue 73412 did not cause this bug it - it /revealed/ it. The real bug - not catching the proper exceptions in DialogWindow::StoreData - is in there for quite a while. With issue 72282 - localization support for the dialog editor -, triggering this bug was made more likely, but did not happen, yet. My fix for issue 73412 was the last piece needed to trigger the real bug.
This works on the MacIntel m200 build with macosxmapfiles cws applied. No crash and the edit window comes right up. Will try with a m5 build. James McKenzie
The CWS which revealed the bug was dba22c, which was integrated in OOF680 m5 (as dba22c_OOF680), and in SRC680 m201. The reason for the crash is platform independent (an uncaught exception), so it should crash on the Mac's m5, too. The good news is I have a fix at hand, I'm just struggling with CWS handling ATM.
fixed in CWS basexc: toolkit/source/controls/dialogcontrol.cxx 1.15.2.1.2.1 basic/inc/namecont.hxx 1.3.4.1.2.1 basic/source/uno/namecont.cxx 1.4.4.1.2.1 basctl/source/basicide/baside3.cxx 1.32.48.1
submitted follow-up issue 74080 - the bug here was fixed by properly catching an exception, which is the least invasive fix for 2.2. However, this exception should not happen at all - the code provoking it should not ran through. This is what issue 74080 is about.
fs-> tbo: please verify in CWS basexc
verified on CWS basexc on linux and win32
*** Issue 74120 has been marked as a duplicate of this issue. ***
integrated in OOF680m7 - closing
*** Issue 74372 has been marked as a duplicate of this issue. ***
*** Issue 75755 has been marked as a duplicate of this issue. ***