Tried to open the Word document in the zip available here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-930.zip Writer did not respond for a few seconds then crashed. Always reproducible. I use Win 7. OOo 3.2 on Ubuntu opens the very same file correctly.
Hi Tor, I am also seeing this problem on Libo 3.3 rc1 Windows XP. The same build on SLED 11 sp1 does NOT have this problem. Would you like to have a review if the impact area can be defined. Thanks!
Even if it crashes only on Windows, I do think Cedric knows the Writer code better. But I will at least try to reproduce and get a stack trace, and then hand over to Cedric if the problem is in Writer code and I don't understand how to fix it.
Can reproduce with a self-built LO from the 3-3 branch.
After opening the .doc file LO kinda hangs for me, without displaying he document. It crashes then when I move the Writer window around a bit and/or move the mouse inside the window. The stack trace at the crash is: > svxcoremi.dll!SdrMarkView::CheckSingleSdrObjectHit(const Point & rPnt={...}, unsigned short nTol=0x001e, SdrObject * pObj=0x10310898, SdrPageView * pPV=0x0721d808, unsigned long nOptions=0x00000007, const SetOfByte * pMVisLay=0x00000000) Line 1701 + 0x1f bytes C++ swmi.dll!0ea55b91() [Frames below may be incorrect and/or missing, no symbols loaded for swmi.dll] svxcoremi.dll!SdrMarkView::CheckSingleSdrObjectHit(const Point & rPnt={...}, unsigned short nTol=0x001e, SdrObjList * pOL=0x101cf248, SdrPageView * pPV=0x0721d808, unsigned long nOptions=0x00000007, const SetOfByte * pMVisLay=0x00000000, SdrObject * & rpRootObj=0x00000000) Line 1742 + 0x29 bytes C++ svxcoremi.dll!SdrMarkView::PickObj(const Point & rPnt={...}, short nTol=0x001e, SdrObject * & rpObj=0x00000000, SdrPageView * & rpPV=0x00000000, unsigned long nOptions=0x00000007, SdrObject * * ppRootObj=0x0145f73c, unsigned long * pnMarkNum=0x00000000, unsigned short * pnPassNum=0x0145f768) Line 1835 + 0x33 bytes C++ svxcoremi.dll!SdrView::PickAnything(const Point & rLogicPos={...}, SdrViewEvent & rVEvt={...}) Line 413 + 0x3c bytes C++ swmi.dll!0ed51808() swmi.dll!0ec459e1() vclmi.dll!Window::PreNotify() + 0x34 bytes C++ 10239128() swmi.dll!0ee91738() vclmi.dll!ImplHandleMouseEvent() + 0xaa3 bytes C++ vclmi.dll!ImplHandleSalMouseMove() + 0x2b bytes C++ vclmi.dll!ImplWindowFrameProc() + 0x3d bytes C++ Unfortunately I couldn't just recompile parts of swmi.dll for debugging for some reason, I got unresolved symbols. Will see if I need to recompile all of sw for debugging.
Will continue debugging, trying to get a better understanding.
With a sw built for debugging, when loading the document in question I get dozens of assertion failures from sw/source/core/txtnode/ndhints.cxx, line 389.
Factoring out the sub-expressions in the assertion into variables, I see that both pHtLast->Which() and pHtThis->Which() have the value RES_TXTATR_AUTOFMT. If I comment out that #if OSL_DEBUG_LEVEL > 1 in SwpHintsArray::Check() and let the import continue, the next failed assertion is in sw/source/filter/ww1/fltshell.cxx, line 166: "Attribut oder AEhniliches ueber Bereiches-Grenzen" If I ignore that assertion a couple of times, I get into the "hang" situation as in comment #4, and then when moving the window a bit I eventually end up with an unhandled exception (access violation). Call stack: vclmi.dll!Region::operator=() + 0x12 bytes C++ vclmi.dll!OutputDevice::ImplInitClipRegion() + 0x5a bytes C++ vclmi.dll!OutputDevice::DrawRect() + 0xc3 bytes C++ > swmi.dll!SwLayIdle::ShowIdle(unsigned long eColorData=0x00ff0000) Line 2375 C++ swmi.dll!SwLayIdle::SwLayIdle(SwRootFrm * pRt=0x0e791488, SwViewImp * pI=0x0e72aa38) Line 2408 C++ swmi.dll!ViewShell::LayoutIdle() Line 640 C++ swmi.dll!SwDoc::DoIdleJobs(Timer * pTimer=0x0e23eaa0) Line 1883 C++ swmi.dll!SwDoc::LinkStubDoIdleJobs(void * pThis=0x0e23e9c0, void * pCaller=0x0e23eaa0) Line 1845 + 0xf bytes C++ tlmi.dll!Link::Call() + 0x11 bytes C++ vclmi.dll!Timer::Timeout() + 0xa bytes C++ etc. Not really like the one in comment #4, so I guess the data structures are so messed up it crashes pretty randomly.
By the way, the call stack at the assertion failure in SwpHintsArray::Check() is: swmi.dll!SwpHintsArray::Check() Line 396 + 0xaa bytes C++ > swmi.dll!SwpHints::DeleteAtPos(const unsigned short nPos=0x0004) Line 2929 C++ swmi.dll!SwpHints::Delete(SwTxtAttr * pTxtHt=0x0e3be1b8) Line 2941 C++ swmi.dll!SwpHints::BuildPortions(SwTxtNode & rNode={...}, SwTxtAttr & rNewHint={...}, const unsigned short nMode=0x0000) Line 875 C++ swmi.dll!SwpHints::TryInsertHint(SwTxtAttr * const pHint=0x0e3be1e8, SwTxtNode & rNode={...}, const unsigned short nMode=0x0000) Line 2851 C++ swmi.dll!SwTxtNode::InsertHint(SwTxtAttr * const pAttr=0x0e3be1e8, const unsigned short nMode=0x0000) Line 1471 + 0x1e bytes C++ swmi.dll!SwTxtNode::SetAttr(const SfxItemSet & rSet={...}, unsigned short nStt=0x000a, unsigned short nEnd=0x0013, const unsigned short nMode=0x0000) Line 1737 + 0x17 bytes C++ swmi.dll!SwRegHistory::InsertItems(const SfxItemSet & rSet={...}, const unsigned short nStart=0x000a, const unsigned short nEnd=0x0013, const unsigned short nFlags=0x0000) Line 1448 + 0x1b bytes C++ swmi.dll!lcl_InsAttr(SwDoc * const pDoc=0x0e23e640, const SwPaM & rRg={...}, const SfxItemSet & rChgSet={...}, const unsigned short nFlags=0x0000, SwUndoAttr * const pUndo=0x00000000) Line 1004 + 0x3d bytes C++ swmi.dll!SwDoc::InsertPoolItem(const SwPaM & rRg={...}, const SfxPoolItem & rHt={...}, const unsigned short nFlags=0x0000) Line 1137 + 0x1d bytes C++ swmi.dll!SwFltControlStack::SetAttrInDoc(const SwPosition & rTmpPos={...}, SwFltStackEntry * pEntry=0x0e352838) Line 606 C++ mswordmi.dll!12c2a8f9() sal3.dll!100069e8() cppu3.dll!cppu::idestructSequence() + 0xc0 bytes C++ cppu3.dll!_STL::_Rb_global<bool>::_Rebalance_for_erase() + 0x532 bytes C++ (for some reason VS doesn't display any more stack in this case)
Tried on XP SP3 with LibreOffice 3.3.0 OOO330m19 (Build:5) tag libreoffice-3.3.0.3 Still crashes. Actually there are quite may 3GPP docs which make LibreOffice crash. It may have something to do with the LTE logo on the opening page. 3GPP docs without that logo seem to open fine. (I opened a dozen of 3GPP docs in both Word and Writer to check this. And the result seems to be consistent with my theory about the logo.)
Found another case when Writer hangs or crashes on Windows 7. The interesting thing is that the embedded image that causes the issue is in the middle of the doc, and Writer functions fine as long as that area is not rendered. http://research.microsoft.com/en-us/um/people/jinl/paper_2002/msri_jpeg.doc
I opened http://research.microsoft.com/en-us/um/people/jinl/paper_2002/msri_jpeg.doc again. Avoiding scrolling down I saved it as ODT. I opened the ODT as ZIP archive and got rid of any picture larger than 3kB. Doing that I removed all the embedded WMF pictures that caused the crash. Then Writer was able to open and render the doc, without of the removed images, of course. So I guess something is wrong with WMF handling.
Still crashes RC4/Win32 LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
With self built LibreOffice 3.3.0 OOO330m19 (Build:5) (OxygenOffice Professional) / Ubuntu 10.10. 32 bit / Built under Ubuntu 8.04 / 32 bit I was able to open the doc, it looks okay, but has few problems around index, illustratons, numbering.
> With self built LibreOffice 3.3.0 OOO330m19 (Build:5) (OxygenOffice > Professional) / Ubuntu 10.10. 32 bit / Built under Ubuntu 8.04 / 32 bit > > I was able to open the doc Yes, the issue seems to be Windows only.
Cedric, do my tracebacks and ponderings above give you any hint where the problem is?
(In reply to comment #15) > Cedric, do my tracebacks and ponderings above give you any hint where the > problem is? Well, I have to admit that I only had a look at them... Is it possible to have a backtrace of the loop? I have no real idea of what is going on... a backtrace of the loop may help to get a starting point.
With v3.3.1 I cannot reproduce the issue on Win 7. Both the referred 3GPP and JPEG docs open fine and can be scrolled from the beginning to the end without any issue. I am happy to see that. Did someone fix the issue or some magic happened? LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2
DOC file in zip archive opens correctly running clean install of LibO 3.3.2rc2 on OSX 10.5.8 (Jre from Apple 1.5.0_28).
I tried using 3.3.2 on Win 7. It works fine. LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2 As I cannot reproduce the issue any longer, I suggest closing this bug report. Thank you for your help. (I still do not know what was the root cause of the issue, though. Strangely, it appeared on Windows only.)