Apache OpenOffice (AOO) Bugzilla – Issue 125741
Crash in Basic IDE on watch of Cell in TableShape
Last modified: 2014-10-25 16:35:06 UTC
Created attachment 84056 [details] document with DrawTable and macro to access cell Set your OpenOffice to allow macros and close all other documents. Open the attached document. It contains a macro. Open the Basic IDE and set a breakpoint on line "dummy = 0" of macro "examine_Cell". Go back to document. There should be a toolbar with button "examine_Cell" to run the macro. Run the macro. It might be, that you need to run it twice to actually stop at the break point. Open IDE. Add variable "oLeftTopCell" to the watch window. Expand the + of it in the watch window. Crash. My debug build gives the error messages: Error: unknown which - dont ask me for defaults with Id/Pos: 3903 From File c:/AOO_debugbuild_420/trunk/main/svl/source/items/itempool.cxx at Line 958 Error: Which-Id nicht im Pool-Bereich From File c:/AOO_debugbuild_420/trunk/main/svl/source/inc\poolio.hxx at Line 207 You can basically access the cell via macro, which is proved by the statement "msgbox oLeftTopCell.getString()". But the access via watch window is faulty.
I can reproduce the described behaviour also with 4.0.1 and a 4.2.0-dev. (Not tested with 3.x.)
maybe releated to: basic ide: inspection of object crashes oo - memory leak https://issues.apache.org/ooo/show_bug.cgi?id=84092
I think, it is not related, see my comment in issue 84092. In addition the inspected object here is a TableShape, which does not exist in OOo2.3.
Created attachment 84096 [details] Modified macro reading property ParaIsNumberingRestart I reproduce the crash with attachment 84056 [details] on Apache OpenOffice 4.1.1 Windows 7. But, doing various editing of the macros, sometimes there is no crash, oLeftTopCell is correctly analyzed by the IDE watch. The crash also happens if I use Xray to analyse oLeftTopCell. This is consistent because Xray and the watch window use the same introspection techniques. Using a debugging version of Xray, I found that the crash occurs when trying to obtain the value of property ParaIsNumberingRestart (of service ParagraphProperties). In my attachment the macro is modified (lines 16,17,18) to read the property oLeftTopCell.ParaIsNumberingRestart which is a boolean. Run the macro, you will see : error 13 at line : 17 Data type mismatch. This error should not happen, this is the symptom of an internal bug.
Each cells can contain multiple paragraphs even numbered and non-numbered together. Numbering related properties are paragraph dependent. So these properties should not be listed on the cell itself, in my opinion. The reson of the crash is these properties are there in the SfxItemPropertyMapEntry but the generated itemset do not have these entries because properties are processed by ::sdr::properties::CellProperties class. These properties should be processed in the each API methods.