Created attachment 44191 [details] Document file that reproduces bug. Right-click "Lani's" to crash. If the string "Lani's" is included in a Writer document with automatic spell checking enabled, it will have the wavy red underline indicating it as a spelling error. If I right-click on that string, Writer will crash. This is 100% reproducible on two different computers. I have attached a sample document that causes this crash. Both computers are running Windows XP Professional SP3 32-bit with LibreOffice v3.3.1. LibreOffice extensions consist of the defaults plus Accentuate v1.0.0, Alternative Searching v1.3.2, DateTime v2.0.3, OxygenOffice Extra Templates US v2.8.0.1, Sun Professional Template Pack II (English) v1.0, and Test Missing Fonts v1.4.4. LibreOffice is configured as "English (Canada)" for both locale setting and default document language. I upgraded from LibreOffice v3.3.0 to v3.3.1 because of this bug, but it is still present. I consider this to be a very serious bug because I have no reason to suspect that there wouldn't be many other magical letter combinations that would also cause data loss due to such crashes. There is a small subset of letter changes that can be made to the "Lani's" string which will also result in a crash, but most do not. Obviously the number of possible replacements are huge, but I have tested the following possibilities, each of which alters only one letter in the string "Lani's": - Replacing the 'L' with 'M' will still crash, but no other uppercase letter will. - No other lowercase replacement for the 'a' will crash. - Replacing the 'm' with 'n' will crash, but no other lowercase letter will. - Replacing the 'i' with any one of "krtuvw" will crash, but no other lowercase letter will. - The apostrophe must remain in order to crash. - The 's' must remain unchanged in order to crash. We are experiencing other crashes with random documents and have as yet noticed no clear pattern. OpenOffice v3.2.1 never crashed under any circumstances for us. LibreOffice is not what we would expect for release quality. What are the possible negative consequences of downgrading back to OOo v3.2.1 for documents that have since been modified using LibreOffice v3.3.0 or v3.3.1?
Reproduced.
A (mostly useless) stack trace from first debug attempt, of stock 3.3.1 binaries. Will build more of it for debugging to get more useful information, unless somebody happens to beat me to it, and can reproduce and fix it with a build suited for debugging they already have lying around... > ntdll.dll!7c9101b3() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!7c910222() ntdll.dll!7c91019b() ntdll.dll!7c9101db() ntdll.dll!7c9101db() ntdll.dll!7c9101db() ntdll.dll!7c910222() ntdll.dll!7c91019b() ntdll.dll!7c9101db() stlport_vc7145.dll!00fe1050() stlport_vc7145.dll!00fe86d1() stlport_vc7145.dll!00fe1050() stlport_vc7145.dll!00fe86d1() stlport_vc7145.dll!00ff3876() stlport_vc7145.dll!00ff9a5b() msvcr90.dll!78583a58() msvcr90.dll!78583b58() gdi32.dll!77f1831d() gdi32.dll!77f1836d() vclmi.dll!020c5119() vclmi.dll!020c522e() vclmi.dll!020c75ee() vclmi.dll!01f78712() vclmi.dll!01f7a73c() swmi.dll!0ebbcc9c() swmi.dll!0ebcacb9() swmi.dll!0eb512b8() swmi.dll!0eb19856() sal3.dll!10003988() stlport_vc7145.dll!00fe1050() cppu3.dll!00fb48d1() swmi.dll!0ea93725() swmi.dll!0ea93c9c() swmi.dll!0ea777fe() swmi.dll!0ee5b29b() swmi.dll!0edb84ba() vclmi.dll!020514d9() vclmi.dll!020514d9() vclmi.dll!020514d9() vclmi.dll!02056e2d() vclmi.dll!02059b06() uxtheme.dll!5b28c406() vclmi.dll!02125fad() vclmi.dll!01f1efac() vclmi.dll!01f1bcb8() vclmi.dll!020ae8e2() sal3.dll!100039a0() vclmi.dll!01f28287() vclmi.dll!021313aa() vclmi.dll!01f1dff7() soffice.bin!0040101b() soffice.bin!0040103c() soffice.bin!004011e6()
Reproduced with LibreOffice 3.3.1 RC2 (1:3.3.0-1lucid1) - Ubuntu 10.04 x86 Linux 2.6.32-28-generic Russian UI I changed OS due to this result.
After building stlport_vc7145.dll, basegfxmi.dll, vclmi.dll and svxcoremi.dll for debugging (because I saw those at the bottom of the stack trace when debugging), I now have this stack trace when I get a crash: > vclmi.dll!WinSalGraphics::invert(long nX=0x0d69b1a0, long nY=0x06c6c6d0, long nWidth=0x06c6c6e8, long nHeight=0x06c6c700, unsigned short nFlags=0xb238) Line 752 C++ 06c6c680() swmi.dll!06ed3725() swmi.dll!06ed3c9c() swmi.dll!06eb77fe() swmi.dll!0729b29b() swmi.dll!071f84ba() vclmi.dll!Window::PreNotify(NotifyEvent & rNEvt={...}) Line 5174 + 0x23 bytes C++ 0d68b828() swmi.dll!06f2c64f() vclmi.dll!ImplCallCommand(Window * pChild=0x06ce2458, unsigned short nEvt=0x0001, void * pData=0x00000000, unsigned char bMouse='', Point * pPos=0x00e9f82c) Line 310 C++ vclmi.dll!ImplHandleMouseEvent(Window * pWindow=0x06bdd240, unsigned short nSVEvent=0x0001, unsigned char bMouseLeave=0x00, long nX=0x000000a1, long nY=0x000000ec, unsigned long nMsgTime=0x0050b8fa, unsigned short nCode=0x0004, unsigned short nMode=0x0000) Line 906 + 0x13 bytes C++ etc I am afraid that building swmi.dll for debugging might be problematic, at least that is my vague memory. But I will try anyway... Interestingly, once I rebuilt the DLLs mentioned first with debugging, I no longer see them being involved in the crash.
It would be great if this is reproducible on Linux, too. Any developer capable of reproducing it on Linux?
OK, here is yet another stack trace, now again with basgfxmi.dll at the bottom (i.e. top, visually...): > basegfxmi.dll!basegfx::B2DHomMatrix::B2DHomMatrix(const basegfx::B2DHomMatrix & rMat={...}) Line 57 + 0x21 bytes C++ vclmi.dll!OutputDevice::GetViewTransformation() Line 1062 + 0x12 bytes C++ svxcoremi.dll!sdr::overlay::OverlayManagerBuffered::invalidateRange(const basegfx::B2DRange & rRange={...}) Line 501 + 0x19 bytes C++ svxcoremi.dll!sdr::overlay::OverlayManager::impApplyAddActions(sdr::overlay::OverlayObject & rTarget={...}) Line 235 C++ svxcoremi.dll!sdr::overlay::OverlayManager::add(sdr::overlay::OverlayObject & rOverlayObject={...}) Line 310 C++ swmi.dll!SwSelPaintRects::Show() Line 534 C++ swmi.dll!SwCrsrShell::UpdateCrsr(unsigned short eFlags=0x0006, unsigned char bIdleEnd=0x00) Line 1770 C++ swmi.dll!SwCrsrShell::ExtendSelection(unsigned char bEnd='', unsigned short nCount=0x0006) Line 2289 C++ swmi.dll!SwEditShell::GetCorrection(const Point * pPt=0x00e9f53c, SwRect & rSelectRect={...}) Line 1089 C++ swmi.dll!SwView::ExecSpellPopup(const Point & rPt={...}) Line 687 + 0x1d bytes C++ swmi.dll!SwEditWin::Command(const CommandEvent & rCEvt={...}) Line 4884 + 0x15 bytes C++ vclmi.dll!ImplCallCommand(Window * pChild=0x06c72288, unsigned short nEvt=0x0001, void * pData=0x00000000, unsigned char bMouse='', Point * pPos=0x00e9f82c) Line 310 C++ vclmi.dll!ImplHandleMouseEvent(Window * pWindow=0x06b21308, unsigned short nSVEvent=0x0001, unsigned char bMouseLeave=0x00, long nX=0x000000a8, long nY=0x000000f0, unsigned long nMsgTime=0x00a5a10f, unsigned short nCode=0x0004, unsigned short nMode=0x0000) Line 906 + 0x13 bytes C++ vclmi.dll!ImplHandleSalMouseButtonDown(Window * pWindow=0x06b21308, SalMouseEvent * pEvent=0x00e9fa40) Line 2069 + 0x48 bytes C++ The rMat in B2DHomMatrix::B2DHomMatrix(const B2DHomMatrix& rMat) seems to be bogus. That is called from basegfx::B2DHomMatrix OutputDevice::GetViewTransformation() const , as return *mpOutDevData->mpViewTransform . That again is called from OverlayManagerBuffered::invalidateRange(const basegfx::B2DRange& rRange) , as aDiscreteRange.transform(getOutputDevice().GetViewTransformation()) . Nothing of this says much to me... There is a fairly verbose comment before that last mentioned location, saying: // add the discrete range to the remembered region // #i75163# use double precision and floor/ceil rounding to get overlapped pixel region, even // when the given logic region has a width/height of 0.0. This does NOT work with LogicToPixel // since it just transforms the top left and bottom right points equally without taking // discrete pixel coverage into account. An empty B2DRange and thus empty logic Rectangle translated // to an also empty discrete pixel rectangle - what is wrong. I wonder if that is relevant to this problem?
Interestingly enough, next time I try the same right-click, the crash happens with this stack trace: > swmi.dll!ViewShell::GetRefDev() Line 1868 + 0x21 bytes C++ 06c70002() swmi.dll!SwTxtCursor::_GetCharRect(SwRect * pOrig=0x06aff4d0, const unsigned short nOfst=0x0002, SwCrsrMoveState * pCMS=0x00e9e9cc) Line 941 + 0x1e bytes C++ swmi.dll!SwTxtCursor::GetCharRect(SwRect * pOrig=0x06aff4d0, const unsigned short nOfst=0x0002, SwCrsrMoveState * pCMS=0x00e9e9cc, const long nMax=0x000007ba) Line 1232 C++ swmi.dll!SwTxtFrm::GetCharRect(SwRect & rOrig={...}, const SwPosition & rPos={...}, SwCrsrMoveState * pCMS=0x00e9e9cc) Line 302 + 0x48 bytes C++ swmi.dll!SwCrsrShell::UpdateCrsr(unsigned short eFlags=0x0006, unsigned char bIdleEnd=0x00) Line 1696 + 0x3e bytes C++ swmi.dll!SwCrsrShell::Pop(unsigned char bOldCrsr=0x00) Line 1996 C++ swmi.dll!SwEditShell::GetCorrection(const Point * pPt=0x00e9f53c, SwRect & rSelectRect={...}) Line 1074 C++ swmi.dll!SwView::ExecSpellPopup(const Point & rPt={...}) Line 687 + 0x1d bytes C++ swmi.dll!SwEditWin::Command(const CommandEvent & rCEvt={...}) Line 4884 + 0x15 bytes C++ vclmi.dll!ImplCallCommand(Window * pChild=0x06c723f0, unsigned short nEvt=0x0001, void * pData=0x00000000, unsigned char bMouse='', Point * pPos=0x00e9f82c) Line 310 C++ vclmi.dll!ImplHandleMouseEvent(Window * pWindow=0x06b21308, unsigned short nSVEvent=0x0001, unsigned char bMouseLeave=0x00, long nX=0x000000a0, long nY=0x000000ef, unsigned long nMsgTime=0x00c1d67f, unsigned short nCode=0x0004, unsigned short nMode=0x0000) Line 906 + 0x13 bytes C++ vclmi.dll!ImplHandleSalMouseButtonDown(Window * pWindow=0x06b21308, SalMouseEvent * pEvent=0x00e9fa40) Line 2069 + 0x48 bytes C++ vclmi.dll!ImplWindowFrameProc(Window * pWindow=0x06b21308, SalFrame * __formal=0x06b0ddd8, unsigned short nEvent=0x0003, const void * pEvent=0x00e9fa40) Line 2396 + 0xd bytes C++ vclmi.dll!ImplHandleMouseMsg(HWND__ * hWnd=0x00220126, unsigned int nMsg=0x00000204, unsigned int wParam=0x00000002, long lParam=0x00ef00a0) Line 3530 + 0x25 bytes C++ I love randomness.
Definitely seems to be heap corruption or something similar. Now when I run VS with symbols also for the MS libraries, I get a crash (i.e. unhandled exception) in malloc(). ntdll.dll!_RtlAllocateHeap@12() + 0xef bytes > msvcr90.dll!malloc(unsigned int size=0x00000008) Line 163 + 0x5f bytes C msvcr90.dll!operator new(unsigned int size=0x00000008) Line 59 + 0x8 bytes C++ vclmi.dll!SimpleWinLayout::LayoutText(ImplLayoutArgs & rArgs={...}) Line 413 + 0x1f bytes C++ vclmi.dll!OutputDevice::ImplLayout(const String & rOrigStr={...}, unsigned short nMinIndex=0x0000, unsigned short nLen=0x0002, const Point & rLogicalPos={...}, long nLogicalWidth=0x00000000, const long * pDXArray=0x00000000, bool bFilter=false) Line 5992 + 0x16 bytes C++ vclmi.dll!OutputDevice::GetTextArray(const String & rStr={...}, long * pDXAry=0x0d1703b8, unsigned short nIndex=0x0000, unsigned short nLen=0x0002) Line 5665 + 0x2e bytes C++ swmi.dll!SwFntObj::GetTextSize(SwDrawTextInfo & rInf={...}) Line 2009 C++ swmi.dll!SwSubFont::_GetTxtSize(SwDrawTextInfo & rInf={...}) Line 762 + 0x13 bytes C++ swmi.dll!SwTxtSizeInfo::GetTxtSize() Line 490 + 0x44 bytes C++ swmi.dll!SwTxtPortion::GetTxtSize(const SwTxtSizeInfo & rInf={...}) Line 565 + 0xc bytes C++ swmi.dll!SwTxtCursor::_GetCharRect(SwRect * pOrig=0x06af04e0, const unsigned short nOfst=0x0002, SwCrsrMoveState * pCMS=0x00e9e9cc) Line 941 + 0x1e bytes C++ swmi.dll!SwTxtCursor::GetCharRect(SwRect * pOrig=0x06af04e0, const unsigned short nOfst=0x0002, SwCrsrMoveState * pCMS=0x00e9e9cc, const long nMax=0x000007ba) Line 1232 C++ swmi.dll!SwTxtFrm::GetCharRect(SwRect & rOrig={...}, const SwPosition & rPos={...}, SwCrsrMoveState * pCMS=0x00e9e9cc) Line 302 + 0x48 bytes C++ swmi.dll!SwCrsrShell::UpdateCrsr(unsigned short eFlags=0x0006, unsigned char bIdleEnd=0x00) Line 1696 + 0x3e bytes C++ swmi.dll!SwCrsrShell::Pop(unsigned char bOldCrsr=0x00) Line 1996 C++ swmi.dll!SwEditShell::GetCorrection(const Point * pPt=0x00e9f53c, SwRect & rSelectRect={...}) Line 1074 C++ swmi.dll!SwView::ExecSpellPopup(const Point & rPt={...}) Line 687 + 0x1d bytes C++ swmi.dll!SwEditWin::Command(const CommandEvent & rCEvt={...}) Line 4884 + 0x15 bytes C++ vclmi.dll!ImplCallCommand(Window * pChild=0x06c622d8, unsigned short nEvt=0x0001, void * pData=0x00000000, unsigned char bMouse='', Point * pPos=0x00e9f82c) Line 310 C++ vclmi.dll!ImplHandleMouseEvent(Window * pWindow=0x06b12308, unsigned short nSVEvent=0x0001, unsigned char bMouseLeave=0x00, long nX=0x000000a2, long nY=0x000000ec, unsigned long nMsgTime=0x00dec56b, unsigned short nCode=0x0004, unsigned short nMode=0x0000) Line 906 + 0x13 bytes C++ vclmi.dll!ImplHandleSalMouseButtonDown(Window * pWindow=0x06b12308, SalMouseEvent * pEvent=0x00e9fa40) Line 2069 + 0x48 bytes C++ vclmi.dll!ImplWindowFrameProc(Window * pWindow=0x06b12308, SalFrame * __formal=0x06afedf8, unsigned short nEvent=0x0003, const void * pEvent=0x00e9fa40) Line 2396 + 0xd bytes C++ vclmi.dll!ImplHandleMouseMsg(HWND__ * hWnd=0x002f0106, unsigned int nMsg=0x00000204, unsigned int wParam=0x00000002, long lParam=0x00ec00a2) Line 3530 + 0x25 bytes C++
Running soffice.bin under an evaluation copy of Purify, when right-clicking the word in question, I see 14 occurrences of FMR (free memory read) in strncmp and 36 occurrences of IPR (invalid pointer read) in strncmp. As it is an evaluation copy, it doesn't show me where, not even in what DLL. Kendy, should we purchase a PurifyPlus license? Can anybody see any problem when running the reproduction case under Valgrind on Linux?
I don't know if it helps, but I had someone try to reproduce this bug using OpenOffice.org v3.3.0 instead of LibreOffice. He suffered no crash, so it seems to be a LibreOffice bug only.
I cannot reproduce this bug with LO 3.3.1 running Windows Vista SP1 x86
(In reply to comment #11) > I cannot reproduce this bug with LO 3.3.1 running Windows Vista SP1 x86 Actually it's SP2, not that it really matters...
(In reply to comment #10) > I don't know if it helps, but I had someone try to reproduce this bug using > OpenOffice.org v3.3.0 instead of LibreOffice. He suffered no crash, so it seems > to be a LibreOffice bug only. I should have also said that he's using Windows 7 rather than Windows XP, so given Zack's test it's also possible that the bug is OS-dependent.
I have reproduced it on windows XP 32 bit LibreOffice 3.3.1.2 (Writer,Calc,Impress) without extensions but can not reproduce on Mandriva 64 bit LibreOffice 3.3.2.1rc1
Created attachment 44533 [details] crash stack on LibO 3.3.1 sled 11 sp1 Hi, I reproduced this on SLED 11 sp1 with LibO 3.3.1. Crash stack attached.
Yifan, great, if it van be reproduced on (some) Linux, it can hopefully be valgrinded... Your crash stack (in free()) definitely seems to indicate heap corruption, too.
gah, I tried to reproduce this as I have a couple of debug builds around, failed miserably, master (64 bit ) - no libreoffice3.3 ( 64 bit ) branch with distro patch - no ( although this self build seems to not even detect the spelling error ( might be to do with missing dictionaries or something ) however ( although I did get a very similar valgrind trace to the stack from yifan ) against the generic 3.3.1 build downloaded from libreoffice site. I will attach the valgrind log ( although without line numbers it's not enough for me to see where it is going wrong ).
Created attachment 44577 [details] valgrind log against 3.3.1 final note the memcpy error is all I get with the current libreoffice3-3 branch and master builds and that error seems benign ( although in theory it could cause some problems )
(In reply to comment #17) > master (64 bit ) - no > libreoffice3.3 ( 64 bit ) branch with distro patch - no ( although this self > build seems to not even detect the spelling error ( might be to do with missing > dictionaries or something ) I should say in this case that I had to set the text language from English (canada ) to English (uk) to get the spelling error
Noel, thanks for the valgrind runs!
I also tried reproducing this bug with my desktop which is running Windows 7 SP1 x64. I was unable to reproduce this bug with any combination of letters that have crashed LO for the OP.
it is 32-bit specific bug it can reproduced on 32 bit windows and Linux but can not reproduced on 64 bit windows and Linux
Sasha, I hope you are aware that on 64-bit Linux, the LibreOffice is also 64-bit code, but for Windows, there is only a 32-bit LibreOffice which is used both on 32- and 64-bit Windows. Thus I don't really give that much value to your last comment. You might be making up the wrong conclusions. Please don't bother with technical guesses if you are not a developer and actually have been debugging the code.
Thanks for explanations
(In reply to comment #22) > it is 32-bit specific bug > it can reproduced on 32 bit windows and Linux > but can not reproduced on 64 bit windows and Linux As tor said, I don't think this is correct. I cannot reproduce this bug on either version of Windows (Vista x68 and 7 x64).
This bug triggered for me in a Windows XP VM (VirtualBox) with OpenOffice 3.3
Bug seems to be fixed in 3.4.