[Libreoffice-bugs] [Bug 127481] EDITING: Crash in sdr::table::Cell::GetItemSet() (on double-click in 1x1 table within duplicated slide)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=127481

--- Comment #17 from Stepas Toliautas <stepas.toliautas at gmail.com> ---
OK, here's what I know so far:

* After table creation dialog, one table and one cell is created.
* On page duplication (SdDrawDocument::DuplicatePage), 
    - in SdrObject::CloneHelper<sdr::table::SdrTableObj>, via 'MakeNewObject', 
        - TableModel with single row and single cell is created (2 cells now).
    But then,
    - SdrObject::CloneHelper<sdr::table::SdrTableObj> tries to fill newly
created object with data from '*this' using 'operator='.
        - TableModel::dispose and Cell::dispose are called along the way,
making just-created cell unusable.
        - TableModel::dispose also activates TableRow::dispose, which calls
Cell::dispose AGAIN. (This double-dispose is checked against as part of earlier
bugfix, tdf#118199.)
    - SdrObject::CloneHelper<sdr::table::SdrTableObj>'s 'operator=' then
        - creates another TableModel with single row and single cell. Since
Cell 2 is only 'disposed of', but not deleted, there are now 3 pointers/
references to dynamically-allocated cells.
    - However, reference to the Cell 2 is kept for future use instead of Cell
3, which later causes the crash that was initially reported here.
    - Either checking for mpProperties != nullptr or not using Cell::GetItemSet
disables/ avoids the crash, but reference assignment is not corrected.
* Additionally, on table focus (single click) drag copy of the table is
temporarily created and then deleted, with the same cell-duplication and
double-dispose effects as described above. This process is repeated on each
focus-unfocus cycle.
* At the end of the program (I choose not to save file), all 3 initial Cell
references are accounted for and deleted, but with multiple dispose calls along
the way.

As I feel really not qualified to make decisions on copy/move semantics, object
disposal and memory management conventions of LO, I would be grateful if
someone more knowledgeable would interject here and try to sort out which parts
of this design are really indisputably wrong and which ones should be worked
around.

Again, either nullptr check or Thorsten's proposal seem to be enough to stop
Impress from crashing. But the ghost-duplicates will remain.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191215/2c4ce47f/attachment.htm>