Issue 80966

Created attachment 47744 [details]
the compare document(contains table)

Yes, I'm able to confirm this issue.

After comparision of the documents the table is marked as "redline deletion".
When the change tracking is accepted, this table will be deleted. The root cause
is the SwUndoDelete object which is created at that moment. The constructor of
SwUndoDelete does not handle the given selection (starting with the table,
ending _behind_ the table) correctly. It sets its member variable nNdDiff to the
wrong value -1 instead of the correct value of 0. When the undo action is
performed it uses this wrong value and tries to access a node outside the
SwNodes array => crash.

The SwUndoDelete::SwUndoDelete method has to become more sophisticated to handle
even such a selection correctly without breaking any other selections!

Reassigned.

Created attachment 47898 [details]
patchfile

I think it could be fixed as long as the nNdDiff isn't set to wrong value.
I submit a patch, if the nNdDiff may be set to -1, it will be set to 0.
Please have a look at it.

->liuyu: Yes, your patch would solve the problem, if nNdDiff becomes negative.
But it could happen that nNdDiff is positive and the crash occurs even with your
patch.
Please insert a footnote into the table of your bug document and do the same
steps as before.
The problem is not the negative value even a negative value is obviously wrong
and must not occur. The real problem is that rPam.GetPoint() does not point to
the position where it should do.

Created attachment 47962 [details]
patchfile

->ama: I find the problem that the pSttTxtNd is a SwTxtNode, but when the 
document start with a table or a section it will be NULL. So I think I could 
add the SwTableNode and the SwSectionNode to the condition( if( !pSttTxtNd 
&& !pEndTxtNd ) ) ,then the nNdDiff will be assigned correct value.

What do you think?

If you add SwSectionNode and SwTableNode to the condition, the condition will
become false in nearly every situation. But this code has to be performed in
some situations, e.g. if you insert a table into an empty document and delete it
with Table/Delete/Table. With your change the Undo operation would crash.
The problem is nNdDiff. The value of nNdDiff at the end of the SwUndoDelete
represents the number of SwNodes which has been deleted (as a side effect) in
front of the "main" deletion. E.g. if you delete some paragraphs in the document
(the "main" deletion) and this paragraphs contains footnotes, as a side effect
the footnote content will be deleted as well. Unfortunately this footnote
content is in our SwNode array in front of the body content. The Undo has to
take care of this "shifts" in the SwNode array.
For simple deletions of text nodes nNdDiff is the difference between the start
index of the deletion before (nSttNode) and after (rPam.GetPoint) the deletion
has been performed. But if the start node and the end nodes of the deletion are
_no_ text nodes, it becomes tricky. In line 259 the watched index will be
decremented and in our problem code in line 387 this decrementation will be
corrected. In our bug case something goes wrong with this decrementation and
correction.

Created attachment 48201 [details]
patchfile

->ama: Under your suggestion, I've submitted a new patch file.
After the rPam.GetPoint() changing, decrement the index, if the start node and 
the end nodes of the deletion are _no_ text nodes.
Please have a look at it. 

->liuyu: Your patch solves the issue. I debugged a little bit and got a feeling
what went wrong with the original code and got repaired with your changes.

->ama: So Could I consider this issue has been fixed, or is there any other 
problem?

No real problem, this issue can be regarded as fixed. Based on your fix I found
another possibility to solve the problem, have a look at my code snippet.

Created attachment 48207 [details]
Another patch

Fixed in CWS swqbf105
undel.cxx

Ready for QA

Verified in CWS swqbf105

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues