Created attachment 91809 [details] Sample doc containing an inline-editable input field. I guess this is an issue since we have inline editing for input fields in Writer. Just moving the mouse into the area of the input field (where the mouse would change from pointer into a hand), and Writer crashes.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fc0bd38051c7c8f4c68a1407aed32a96b2564510 fdo#73466 SwTxtSizeInfo / SwTxtInputFldPortion: invalid string access The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7baa6fe82c9d4f8bc6841f82f04088e664dda08&h=libreoffice-4-2 fdo#73466 SwTxtSizeInfo / SwTxtInputFldPortion: invalid string access It will be available in LibreOffice 4.2.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The bug reoccurs in master. Of course it can be handled similarly, add another check (nPos >= 0), but the root cause is elsewhere. I see big negative offsets in debugger. Breakpoint 1, SwTxtInputFldPortion::GetExpTxt (this=0x2c00440, rInf=..., rTxt="") at /home/timar/libreoffice-master/sw/source/core/text/portxt.cxx:775 775 sal_Int32 nIdx = rInf.GetIdx(); (gdb) n 776 sal_Int32 nLen = rInf.GetLen(); (gdb) n 777 if ( rInf.GetChar( rInf.GetIdx() ) == CH_TXT_ATR_INPUTFIELDSTART ) (gdb) p nLen $14 = -2147483516 (gdb) p nIdx $15 = 133 (gdb) p rInf $16 = (const SwTxtSizeInfo &) @0x7fffffff2da0: {<SwTxtInfo> = {pPara = 0x2c28c80, nTxtStart = 0}, m_aMaxWidth = std::__debug::map with 0 elements, m_pKanaComp = 0x0, m_pVsh = 0x2954910, m_pOut = 0x2950220, m_pRef = 0x289d0b0, m_pFnt = 0x290c520, m_pUnderFnt = 0x0, m_pFrm = 0x2955cf0, m_pOpt = 0x2954f90, m_pTxt = 0x23e4d18, m_nIdx = 133, m_nLen = -2147483516, m_nKanaIdx = 0, m_bOnWin = true, m_bNotEOL = false, m_bURLNotify = false, m_bStopUnderflow = false, m_bFtnInside = false, m_bOtherThanFtnInside = false, m_bMulti = false, m_bFirstMulti = false, m_bRuby = false, m_bHanging = false, m_bScriptSpace = false, m_bForbiddenChars = false, m_bSnapToGrid = true, m_nDirection = 0 '\000'} Bisecting showed, that the issue was introduced in 323d10c7975c34125009694a42c476ce83f031c4..a700ce8e2b2f2dad50bf36dfd69de577211f1dc3 range, where the big xub_Strlen -> sal_Int32 changes happened.
By the way, I used https://bugs.freedesktop.org/attachment.cgi?id=95894 as test document.
sw/source/core/text/itrcrsr.cxx:1632 SwTxtSizeInfo aSizeInf( GetInfo(), &rText, nCurrStart ) where nCurrStart is non 0 and the hidden 4th argument to SwTxtSieInfo is COMPLETE_STRING in the past it was STRING_LEN unsigned 16bit 0xFFFF and so in GetMinLen in sw/source/core/text/inftxt.cxx adding x to it resulted in x-1 so std::min on that gave an in-bounds value
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e5e61dc529cf359309d3cdb944760905e5262c5 Resolves: fdo#73466 overflow on addition to COMPLETE_STRING The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.