Apache OpenOffice (AOO) Bugzilla – Issue 73247
Basic: crash when looking at a TextSection
Last modified: 2013-08-07 14:43:03 UTC
Happy new year at all of you. In the basic framework, create a macro which creates a textsection. With the debugger, try to visit the content of the textsection. OOo crashes. Open the attached document, and edit the Module1/Main macro. Put a breakpoint on the MsgBox statement. try to look at "aSection". I'm using OOo 2.1 (680m6) on Linux. Best Reagard.
Created attachment 41996 [details] A macro creating a TextSection
Reassigned to JSK.
Confirming with OO 2.1 on both WinXP and Suse 10.2. To reproduce 1. Open attached file, enabling macros. 2. Go to OO basic, set breakpoint, add watch for "aSection". 3. Click "Step into" (see attached screenshot), then "Run BASIC", then click '+' sign next to "aSection" - OO crashes.
Created attachment 42012 [details] Illustrating screenshot
This problem already exists with Win XP on 2.0.4 and 1.1.5. Crash does not appear after text section is inserted: aSection = thisComponent.createInstance("com.sun.star.text.TextSection") dim curs as object curs = thisComponent.Text.createTextCursor curs.gotoEnd(False) thisComponent.Text.insertTextContent(curs, aSection, False) MsgBox("Please look at the TextSection")
Nice report with fancy screenshot. Thanks! Forwarding to AB, set target 2.2 and raise prio to 2 (crash justifies for this)
Crash is produced by reading properties StartRedLine or EndRedLine. aSection = thisComponent.createInstance("com.sun.star.text.TextSection") dim foo foo = aSection.StartRedLine ' will crash
ab->fme: As discussed to you
FME: Changed target to 2.x.
Cannot be fixed until code freeze => target 3.0
.
May be you can close this issue. I can't reproduce it this OOo 2.4 Regards, Ph.
lijian->fme: This issue still exists in OpenOffice.org 3.0(DEV300_M5). Here is my patch for this issue. Please have a look. The main cause is references to null pointers.
Created attachment 53662 [details] patch file
fme->lijian: Have a look at this basic code: Sub Main curs = thisComponent.Text.createTextCursor curs.gotoEnd(False) ' Table: aTable = thisComponent.createInstance("com.sun.star.text.TextTable") foo = aTable.StartRedLine ' => exception thisComponent.Text.insertTextContent(curs, aSection, False) foo = aTable.StartRedLine ' => ok ' Section: aSection = thisComponent.createInstance("com.sun.star.text.TextSection") foo = aSection.StartRedLine ' => crash thisComponent.Text.insertTextContent(curs, aSection, False) foo = aSection.StartRedLine ' => ok End Sub I think the way it works with tables is correct, an exception is thrown if the property could not be retrieved (because the object has not been inserted yet). Please have a look at unotbl.cxx to see how this works for tables.
lijian->fme: Please have a look. But I am not sure. Actually I don't make the conditions to throw exceptions for uno table clear.
Created attachment 53817 [details] patch file
fme->lijian: I had a second look at the code in unosect.cxx and unotbl.cxx. If a new table or section is created, it is only in a 'descriptor' state. You can set/get a couple of properties which are collected in SwTextSectionProperties_Impl or aTableDescPropertyMap_Impl. Once the section or table is inserted into the document (attachToRange), these properties are passed to the Writer core object (which is created inside attachToRange). So what do we expect if we have a not-yet-attached table (or section) and we ask for a property which has not been set or which is not allowed to be set in descrptor mode? For tables, an exception is thrown. I think this should happen for sections as well. I'll discuss this with OS, who knows this code pretty well. Please stay tuned...
fme->lijian: I discussed this with OS. Right now, a not-yet-attached table throws an exception when calling getPropertyValue() for a property that either has not been set yet or a property that cannot be set (like the StartRedLine property). A not-yet-attached section simply returns a default value in this case. Throwing an exception when accessing StartRedLine would be somewhat inconsistent with the behavior when accessing e.g., the IsProtected flag of the section (here we do not throw an exception but return the default value). Not throwing an exception when accessing StartRedLine would be somewhat inconsistent with the behavior of a not-yet-attached table when accessing StartRedLine. So we have to choose and OS and I agreed upon not throwing an exception but to simply catch the 0-pointer as you did in your first patch. I'll integrate your patch and we consider this issue 'fixed'. Thank you for your work on this.
Fixed in cws fmepatches02, unosect.cxx.
lijian->fme: Thank you for your help.
Ready for QA.
Works ok, verified.
Fixed, closed.