Issue 80966 - crash when compare document (contains table)
Summary: crash when compare document (contains table)
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 2.2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
Depends on:
Blocks: 72764
  Show dependency tree
Reported: 2007-08-23 10:13 UTC by liuyu
Modified: 2013-08-07 14:42 UTC (History)
5 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

the compare document(contains table) (6.82 KB, text/plain)
2007-08-23 10:17 UTC, liuyu
no flags Details
patchfile (702 bytes, text/plain)
2007-08-31 03:42 UTC, liuyu
no flags Details
patchfile (1.11 KB, text/plain)
2007-09-05 06:42 UTC, liuyu
no flags Details
patchfile (828 bytes, text/plain)
2007-09-12 16:26 UTC, liuyu
no flags Details
Another patch (926 bytes, text/plain)
2007-09-13 08:58 UTC, andreas.martens
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description liuyu 2007-08-23 10:13:11 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.
Comment 1 liuyu 2007-08-23 10:17:08 UTC
Created attachment 47744 [details]
the compare document(contains table)
Comment 2 andreas.martens 2007-08-23 12:48:10 UTC
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!
Comment 3 andreas.martens 2007-08-23 12:49:47 UTC
Comment 4 liuyu 2007-08-31 03:42:03 UTC
Created attachment 47898 [details]
Comment 5 liuyu 2007-08-31 03:50:42 UTC
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.
Comment 6 andreas.martens 2007-08-31 15:56:20 UTC
->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
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.
Comment 7 liuyu 2007-09-05 06:42:26 UTC
Created attachment 47962 [details]
Comment 8 liuyu 2007-09-05 07:28:03 UTC
->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?
Comment 9 andreas.martens 2007-09-05 09:28:22 UTC
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
Comment 10 liuyu 2007-09-12 16:26:59 UTC
Created attachment 48201 [details]
Comment 11 liuyu 2007-09-12 16:37:35 UTC
->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. 
Comment 12 andreas.martens 2007-09-12 18:10:24 UTC
->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.
Comment 13 liuyu 2007-09-13 02:45:07 UTC
->ama: So Could I consider this issue has been fixed, or is there any other 
Comment 14 andreas.martens 2007-09-13 08:56:35 UTC
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.
Comment 15 andreas.martens 2007-09-13 08:58:19 UTC
Created attachment 48207 [details]
Another patch
Comment 16 andreas.martens 2007-09-13 10:33:59 UTC
Fixed in CWS swqbf105
Comment 17 andreas.martens 2007-10-24 09:32:13 UTC
Ready for QA
Comment 18 eric.savary 2007-11-05 13:26:17 UTC
Verified in CWS swqbf105
Comment 19 thorsten.ziehm 2009-07-20 14:55:35 UTC
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 =>
If you want to know more about the handling of fixed/verified issues =>