Seems meanwhile I found the reason why it crashes thanks to your hint :) The fix is at http://pastebin.com/fsNFBwqY and the reason was that even when the line wasn't fitting (cause it had a width of zero for example) we still added one character to it. Will test a bit more, add an infinite loop test and the commit. Guess we can probably still apply your idea as Q_ASSERT (and comment) to make sure that a) we are dealing with the proper frames and b) others are able to understand what that code is supposed to do / how things are working together.
On Wednesday 15 June 2011 13:52:22 Sebastian Sauer wrote: > Dag Andersen wrote: > > I'm looking into a crash which happens when textshapes is edited and the > > shape is not on page 1. This is a general case of header/footer crash > > reported in: https://bugs.kde.org/show_bug.cgi?id=273945 > > > > AFAICS the problem is in KWRootAreaProvider::provide(). > > It seems to mix up which page number to use when searching for frames on > > a page. I don't fully understand how it is meant to work so I need help > > with that. > > The att. hack seems to fix the problem but is, well, just a hack. > > Thank you so much for the patch. I would suggest to change the patch to; > > QList<KWFrame *> frames; > if (KWord::isHeaderFooter() // m_textFrameSet->frameCount() > 0) { // work > around bug 273945 > frames = kwdoc->frameLayout()->framesOn(m_textFrameSet, m_textFrameSet- > > >pageManager()->page(m_textFrameSet->frames().at(0)->shape()).pageNumber()) > >; > > } else { > frames = kwdoc->frameLayout()->framesOn(m_textFrameSet, pageNumber); > } > > to make sure that we only fall into the workaround-case if we are dealing > with headers/footers. And then please commit. I did some tests and it > indeed seems there are no regressions with the patch. So, great work! :-) > > How it's meaned to work; > > Every header/footer frameset can hold a collection of n frames. The first > frame in that collection is the "master frame" while all following ones are > copy-frames. Copy-frames do mirror the master-frame to display the same > content within n different shapes. We can have multiple framesets for > headers and footers cause every page-style gets it's own > header/footer-frameset. > > What we do now in that framesOn-line is to fetch all the frames that are > already known in the frameset we are dealing with. We determinate the > frames that are on a page by using there absolutePositions. > > Now what the patch changes is that we don't catch the copy-frames any > longer and deal with them but always take the master-frame and use that > one for every root-area (so, also for those root-areas that are supposed > to use the copy- frame). > > The question now is why it crashes if we are using the copy-frame/shape > rather then the master-frame/shape? That's what I wasn't able to figure > out yet :-/ But then the patch shows that we probably don't need to use > copy-frames at all what would make the code way more easy... Will look > into that within next days as time permits. > > So, all in all: thanks Dag for the great investigation+hint+fix :-) _______________________________________________ calligra-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/calligra-devel
