Apache OpenOffice (AOO) Bugzilla – Issue 80966
crash when compare document (contains table)
Last modified: 2013-08-07 14:42:49 UTC
1,create a swriter document input sth. . 2,use 'compare document' operation compare with another swriter document(contains table). 3,select 'Accept All' on the 'Accept or Reject Changes' dialog. 4,then undo, crash.
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