Issue 121134

Summary: Aoo crashes while opening the MS Word document
Product: Writer Reporter: wujinlong
Component: codeAssignee: AOO issues mailing list <issues>
Status: CLOSED FIXED QA Contact:
Severity: Major    
Priority: P2 CC: lilinyi921734, phoenix.wanglf, zhangjf
Version: 4.0.0-dev   
Target Milestone: 4.0.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
Test document
Patch wujinlong: review?

Description wujinlong 2012-09-28 03:24:05 UTC
Created attachment 79668 [details]
Test document

When opening the test MS Word document (attached), Aoo crashes.
Comment 1 wujinlong 2012-09-28 06:00:21 UTC
Created attachment 79671 [details]

The crash is related with fix for bug 119657. There is a bug in the solution. If revert the fix, Aoo will not crash.

In the test document, there is a special case not covered. The "AbstractNum id 0" has a style link to style "MinDList", which references "Num id 8". At the same time, "AbstractNum id 0" has a complete level definition. 

When processing "num id 1", it finds that the AbstractNum it points to, which is "AbstractNum id 0", has a style linked. Then it will use the style name to find the Num it uses, which is "Num id 8". Since the Num is processed in sequence, "Num id 8" is not processed at that moment. So it will fail to retrieve the AbstractNum "Num id 8" uses, which should be "AbstractNum id 0".

According to the logic of fix for 119657, in such case, the "AbstractNum id 0" would not be created  successfully. In fact, we should create the number rule using the level definitions defined in "AbstractNum id 0", rather than look for the style link. 

The above explains the bug in previous solution, however the reason why the Aoo crashes is not clear. I've tried to attach the soffice process, when Aoo crashes, the Visual Studio can't show any meaningful call stack to determine where Aoo crashes.

But if I add two lines of code to the previous fix, Aoo will not crash. So I suppose the crash is related with unsuccessful creation of Number rule for "AbstractNum id 0".

This new fix is to return the current AbstractNum if can't find a correct AbstractNum through style link, which gos the same path as previous (without the previous fix).

-------------- numbering.xml -------------
<w:abstractNum w:abstractNumId="0">
  <w:nsid w:val="22A540F9"/>
  <w:multiLevelType w:val="multilevel"/>
  <w:tmpl w:val="22AC870E"/>
  <w:styleLink w:val="MinDList"/>
  <w:lvl w:ilvl="0">
<w:num w:numId="1">
  <w:abstractNumId w:val="0"/>
<w:num w:numId="8">
  <w:abstractNumId w:val="0"/>
------- style.xml------
<w:style w:type="numbering" w:customStyle="1" w:styleId="MinDList">
  <w:name w:val="MinD List"/>
  <w:rsid w:val="00E278DA"/>
      <w:numId w:val="8"/>
Comment 2 zhang jianfang 2012-10-25 13:31:27 UTC
Mark as confirmed.
Comment 3 SVN Robot 2012-10-25 13:58:21 UTC
"zhangjf" committed SVN revision 1402153 into trunk:
#i121134#, more fix for i119657, fallback to old logic to use current Abstrac...
Comment 4 zhang jianfang 2012-10-25 14:02:10 UTC
The analysis is clear enough and I think it is acceptable to fallback to old logic when the AbstractNum can not be found.

delivered the code and mark the bug as resolved.
Comment 5 zhang jianfang 2012-10-25 14:05:30 UTC
*** Issue 121199 has been marked as a duplicate of this issue. ***
Comment 6 Li Feng Wang 2012-11-08 07:20:11 UTC
Verified pass on trunk r1404513.
Comment 7 2013-07-11 08:17:18 UTC
Updated target to release that will contain the fix.