Created attachment 88758 [details]
Much simpler test case by removing most of the document

I cleaned up the test case to get to the root of the crash and it seems to be related to the table layout.
The opendocument parsing code seems perfectly fine with it, but the layout end up in an infinite loop…
words(6075)/kword KWDocument::insertPage: pageNumber= 1023
With this simpler test case, the debugging should be simpler

It seems to have a row that is not high enough to hold any text. I wonder if that is where the layout goes wrong

I mean if it cant fit the text it might try to move the row to the next page hoping it will have a higher row there - but if the reason is the row height rather than remaining space on paper then it will never fit and thus give us an infinite loop

I just don't get it that I haven't taken that into consideration - I know I have - so there must be some special condition here that I haven't considered

I confirm, drop the «empty» row (lines 516-523 of the new content.xml file) and it will work.
But the row is not exactly empty, it contains an empty paragraph. That may change a lot of things.

I think it might be this:

    if (noCellsFitted && row <= d->headerRows) {
        d->totalMisFit = true;
    }

That needs to be a bit more complex and check if additionally we are limitedByPage 

for that we need a change further up to now look like:

            qreal maxBottom = maximumAllowedBottom();
            bool limitedByPage = true;
            if (rowHasExactHeight && d->rowPositions[row] + rowHeight <= maxBottom) {
                  limitedByPage =  false;
                  maxBottom = d->rowPositions[row] + rowHeight;
            }

However I am not sure if this will not crash during paint and/or edit as the paragraph inside is not layouted

Created attachment 88890 [details]
Workaround this crash - just to help discuss further

This fix (well, this hack so far) hints the area of layouting code where, as far as I understand, the problem is. I submit it here to help finding a real fix.

Comment on attachment 88890 [details]
Workaround this crash - just to help discuss further

yes, it's something like this, however:

- we can't set maxBottom this late as the border thickness was subtracted above
- the  "&& !rowHasExactHeight" test is too aggressive as there might be cases where we would want to nuke and layout the row on the next page. What we only want is to prevent the case of no line fitting at all due to exact height to cause a nuke because then we end in an endless loop

Git commit bed9cf6b7eaf8e05cb1c78e5a5de036bd6c61569 by Pierre Ducroquet.
Committed on 02/10/2014 at 19:49.
Pushed by ducroquet into branch 'master'.

Check cell size constraints against rerow height

If the requested row height for the cell is not enough to old borders
and padding, we force the layouting to happen nevertheless in order
to prevent infinite looking for space.

Testing done on the test case for bug 293337 containing both 'real'
cells and small cells : no more infinite loop.

REVIEW: 120468

M  +13   -2    libs/textlayout/KoTextLayoutTableArea.cpp

http://commits.kde.org/calligra/bed9cf6b7eaf8e05cb1c78e5a5de036bd6c61569