Problem description: Crash applying AutoCorrect Steps to reproduce: 1. Open Writer 2. Type or copy/paste some text 3. Select Format > AutoCorrect > Apply and Edit Changes Current behavior: Crash Expected behavior: No crash... Operating System: Windows 7
It's a regregression
Looks nasty - thanks for the report. What would -really- help would be a stack trace with debugging symbols. Does this happen with 4.0 as well ?
(In reply to comment #2) > Does this happen with 4.0 as well ? No crash in version 4.0 beta 1 for me. Tested version: 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
crashes in LibO 3.6.3 and 3.6.1 as well. it would be nice to test in 3.6.0 and 3.5.x branch as well. I confirm it doesn't crash on a recen LibO 4.0 beta version.
(In reply to comment #2) > Looks nasty - thanks for the report. What would -really- help would be a > stack trace with debugging symbols. I can confirm at least on 3.6.3.2. Will try to deliver bt after the weekend.
works in LibO 3.5.7. probably a regression of the 3.6.0 or 3.6.1 release.
On pc Debian x86-64 with 3.6 sources udpated 2 days ago (commit 8454a88e1818fa498c6860a2db434ad51591257c), I don't reproduce this. Tommy: on which env are you? Could it be a Windows only bug?
my tests were performed on Windows XP 32bit and Vista 64bit
Created attachment 71639 [details] Bug 58278 - WinDbg session Confirmed with: LO 4.0.0.0.alpha1+ Build ID: own W7 debug build (400m0(Build:1)) Windows 7 Professional SP1 64 bit Attached full WinDbg session.
I still do NOT confirm crash on Version 4.0.0.0.beta1+ (Build ID: 546faa79bf3b1e4b222f182d43a9839106a398d) tried in on Vista 64bit and 7 64bit. it crashed instead on various 3.6.x versions
I guess this is: 00cbe328 5934321f 00000000 00cbe370 5948ae0f swlo!std::vector<String,std::allocator<String> >::size+0xd [c:\program files\microsoft visual studio 9.0\vc\include\vector @ 726] 00cbe334 5948ae0f 0000000e 692e2e9c 00cb0000 swlo!std::vector<String,std::allocator<String> >::operator[]+0xf [c:\program files\microsoft visual studio 9.0\vc\include\vector @ 768] 00cbe370 5948daf7 0000000e 00cbe494 00cbe3c0 swlo!SwAutoFormat::_SetRedlineTxt+0x5f [d:\losrc\4\sw\source\core\edit\autofmt.cxx @ 293] 00cbe380 5948e382 0000000e 692e2e2c 692e2e50 swlo!SwAutoFormat::SetRedlineTxt+0x27 [d:\losrc\4\sw\source\core\edit\autofmt.cxx @ 241] 00cbe3c0 594924cf 692e29b0 00000000 01000000 swlo!SwAutoFormat::BuildText+0x32 [d:\losrc\4\sw\source\core\edit\autofmt.cxx @ 1396] Which is ( I suppose ) wandering off the end of the vector: if( STR_AUTOFMTREDL_END > nActionId ) { sTxt = ViewShell::GetShellRes()->GetAutoFmtNameLst()[ nActionId ]; Although the line numbers are certainly v. odd. It'd be lovely to know what is in that vector in the debugger I guess. The MS debugger doesn't appear to show method arguments - so I'll just assume that nAction is 0x0e - from the frames that seems plausible.
If it is 0xe - that is only 14 - which is less than 22 - and should cause no - unless the vector fill is failing. sw/inc/comcore.hrc:#define STR_AUTOFMTREDL_END 22 sw/source/core/edit/autofmt.cxx: if( STR_AUTOFMTREDL_END > nActionId ) sw/source/ui/utlui/initui.cxx: pAutoFmtNameLst->reserve(STR_AUTOFMTREDL_END); sw/source/ui/utlui/initui.cxx: for( sal_uInt16 n = 0; n < STR_AUTOFMTREDL_END; ++n )
bfoman - any chance of some more digging in that vector ? it -should- be initialized nicely to have valid content of the right size in ImpAutoFmtNameListLoader::ImpAutoFmtNameListLoader( std::vector<String>& rLst ) : Resource( ResId(RID_SHELLRES_AUTOFMTSTRS, *pSwResMgr) ) Worth checking that ~ShellResource is never called I suppose too... oh wait ! this is a -3-6 only crash ? I'm looking at 4.0 which (supposedly) works fine right ? no wonder the line-numbers are/were a bit odd ;-)
(In reply to comment #13) > bfoman - any chance of some more digging in that vector ? I can type in the WinDbg command line whatever you deliver. > oh wait ! this is a -3-6 only crash ? I'm looking at 4.0 which (supposedly) > works fine right ? no wonder the line-numbers are/were a bit odd ;-) This bt is from 4.0.0.0.alpha1+.
actually i can reproduce this on Linux with 3.6.4.3... but not current libreoffice-3-6 as it turns out it's already fixed :) by a0926265dbfc617603cfa1fb8a4a22a5663183fe *** This bug has been marked as a duplicate of bug 56549 ***