Download it now!
Bug 58278 - FORMATTING: Crash applying AutoCorrect
Summary: FORMATTING: Crash applying AutoCorrect
Status: RESOLVED DUPLICATE of bug 56549
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.4.3 release
Hardware: Other All
: high critical
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: regression
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-12-14 06:34 UTC by vitriol
Modified: 2012-12-17 19:10 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug 58278 - WinDbg session (21.10 KB, text/plain)
2012-12-17 10:06 UTC, bfoman (inactive)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vitriol 2012-12-14 06:34:22 UTC
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
Comment 1 vitriol 2012-12-14 06:35:58 UTC
It's a regregression
Comment 2 Michael Meeks 2012-12-14 09:25:15 UTC
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 ?
Comment 3 vitriol 2012-12-14 12:58:39 UTC
(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)
Comment 4 tommy27 2012-12-14 13:19:30 UTC
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.
Comment 5 bfoman (inactive) 2012-12-14 16:11:59 UTC
(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.
Comment 6 tommy27 2012-12-14 17:32:53 UTC
works in LibO 3.5.7.

probably a regression of the 3.6.0 or 3.6.1 release.
Comment 7 Julien Nabet 2012-12-15 00:18:43 UTC
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?
Comment 8 tommy27 2012-12-15 07:39:58 UTC
my tests were performed on Windows XP 32bit and Vista 64bit
Comment 9 bfoman (inactive) 2012-12-17 10:06:58 UTC
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.
Comment 10 tommy27 2012-12-17 10:13:52 UTC
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
Comment 11 Michael Meeks 2012-12-17 11:51:41 UTC
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.
Comment 12 Michael Meeks 2012-12-17 11:53:13 UTC
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 )
Comment 13 Michael Meeks 2012-12-17 12:12:57 UTC
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 ;-)
Comment 14 bfoman (inactive) 2012-12-17 15:13:41 UTC
(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+.
Comment 15 Michael Stahl (CIB) 2012-12-17 19:10:19 UTC
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 ***