I've been working on the crashing-endnote-creation-undo bug.
I don't know what to do next; it's as if I'm pretty close to a
solution but I just need someone else to look at this code and
give me a useful idea.
THE PROBLEM:
When we create an endnote section, we proceed as follows:
- fv_View.cpp, insertEndnoteSection(const XML_Char ** blkprops, const XML_Char **
blkattrs); lines 7151-...
// Now create the endnotes section
// First, do a block break to finish the last section.
UT_uint32 iPoint = getPoint();
m_pDoc->insertStrux(getPoint(), PTX_Block);
// ... snip ...
// Now Insert the endnotes section.
// Doing things this way will grab the newly inserted block
// and put into the endnotes section.
m_pDoc->insertStrux(iPoint, PTX_SectionEndnote);
So the PTX_Block strux is created, then the PTX_SectionEndnote strux.
Great; the piece table and layout classes have a consistent structure.
The PTX_SectionEndnote contains a pointer to the PTX_Block. Alas!
the change history is wrong. It contains the instruction to create
the PTX_Block before the instruction to create the
PTX_SectionEndnote...
DISASTER:
When we undo, we travel back up the change history. That means that
the PTX_SectionEndnote is freed, and it contains a pointer to the
PTX_Block. (More precisely, fl_SectionLayout.cpp:121 is the culprit.)
It goes ahead and frees the fl_BlockLayout, because it thinks it owns
this piece of memory.
Unfortunately, the undo proceeds to undo the PTX_Block creation. This
doesn't work; it's already been freed. The resulting error crashes
valgrind.
THOUGHTS:
Something similar goes on in the header/footer code, but I suspect that
something's a bit wonky there. In any case, I get an annoying crash
with endnotes, and I now know why it's happening, but not how to fix it.
If someone could propose a situation, that would be really cool.
Next message: a commit of some endnote stuff.
pat
