Crash applying AutoCorrect
Steps to reproduce:
1. Open Writer
2. Type or copy/paste some text
3. Select Format > AutoCorrect > Apply and Edit Changes
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: 22.214.171.124.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 126.96.36.199. 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
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 188.8.131.52.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: 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 184.108.40.206.alpha1+.
actually i can reproduce this on Linux with 220.127.116.11...
but not current libreoffice-3-6 as it turns out it's already fixed :)
*** This bug has been marked as a duplicate of bug 56549 ***