Download it now!
Bug 38000 - Document crash with a closing parenthesis on the beginning of a line
Summary: Document crash with a closing parenthesis on the beginning of a line
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86-64 (AMD64) Windows (All)
: medium major
Assignee: Michael Meeks
URL:
Whiteboard:
Keywords: regression
: 38077 38736 (view as bug list)
Depends on:
Blocks: mab3.4
  Show dependency treegraph
 
Reported: 2011-06-06 10:41 UTC by Nicolas R
Modified: 2011-10-29 08:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas R 2011-06-06 10:41:48 UTC
Hello, 

French version of LibO 3.4 (not RC2). Installation done over an existing 3.3.2 version

Launch LibO 3.4
New Text Document
Type a closing parenthesis as the first character of a line, then space (or semi colon)
Crash !

It reminds me a previously corrected bug on OpenOffice ( but I can't remember which one ?), something link to spell checker ...

Same bug anyone ?
Comment 1 vitriol 2011-06-06 10:48:44 UTC
I confirm, language independent.
Comment 2 vitriol 2011-06-06 10:55:19 UTC
No problem in version 3.3.2. Regression.
Comment 3 tester8 2011-06-06 11:56:40 UTC
Not reproduced with Ubuntu 10.04.2
LO 3.4
Comment 4 vitriol 2011-06-06 12:01:15 UTC
Maybe Windows specific.
Comment 5 Nicolas R 2011-06-07 01:22:06 UTC
Same problem with existing writer documents. If you begin a newly inserted line with a closing parenthesis + space ( or semi colon) => crash.

Nota: if you type space then closing parenthesis then space : no problem. 

When you launch again LibO after crash, you accept the recovery, you save the recovered document (Ctrl + S) ... and then you can begin a line with ") " ( but only for few lines) ...
Comment 6 Rainer Bielefeld Retired 2011-06-07 02:31:10 UTC
[Reproducible] with "LibreOffice 3.4.0RC2  – WIN7  Home Premium  (64bit) English UI [OOO340m1 (Build:12)]".

This problem seems to be autocorrect dependent and also happens in other applications, at least in CALC. My results are not100% reproducible, but it seems that the problem disappears more or less when "Replace Dashes" is unchecked in menu 'Tools > Autocorrect > Options'
Comment 7 Rainer Bielefeld Retired 2011-06-07 02:43:29 UTC
DRAW also is affected and it seems that also options "Add non breaking ..." and "Format ordinal numbers" in 'Tools > Autocorrect > Localized Options' have to be checked as condition for the crash.
Comment 8 Michael Meeks 2011-06-07 07:37:30 UTC
I'll look into it; thanks.
Comment 9 Michael Meeks 2011-06-07 07:48:37 UTC
Thankfully it is tractable inside valgrind; for people repeating this sort of bug on Linux - it is great to do:

export G_SLICE=always-malloc
export MALLOC_CHECK_=2

and then run libreoffice under valgrind (slow I know), and attach the output:

$ valgrind ./soffice.bin -writer 2>&1 | tee /tmp/val-log

==9587== Invalid read of size 2
==9587==    at 0x536E238: String::GetChar(unsigned short) const (string.hxx:554)
==9587==    by 0x536CC6F: CharClass::isDigit(String const&, unsigned short) const (charclass.cxx:255)
==9587==    by 0x104358BE: SvxAutoCorrect::FnChgOrdinalNumber(SvxAutoCorrDoc&, String const&, unsigned short, unsigned short, unsigned short) (svxacorr.cxx:524)
==9587==    by 0x10438DE9: SvxAutoCorrect::AutoCorrect(SvxAutoCorrDoc&, String const&, unsigned short, unsigned short, unsigned char, Window*) (svxacorr.cxx:1418)
==9587==    by 0xFAA877F: SwEditShell::AutoCorrect(SvxAutoCorrect&, unsigned char, unsigned short) (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0xFEF8153: SwWrtShell::AutoCorrect(SvxAutoCorrect&, unsigned short) (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0xFE07339: ??? (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0x575EE83: ImplHandleKey(Window*, unsigned short, unsigned short, unsigned short, unsigned short, unsigned char) (in /data/opt/libreoffice/libreoffice-3-4/clone/libs-gui/vcl/unxlngi6.pro/lib/libvclli.so)

... and ...

==9587== Conditional jump or move depends on uninitialised value(s)
==9587==    at 0x536CC7B: CharClass::isDigit(String const&, unsigned short) const (charclass.cxx:256)
==9587==    by 0x104358BE: SvxAutoCorrect::FnChgOrdinalNumber(SvxAutoCorrDoc&, String const&, unsigned short, unsigned short, unsigned short) (svxacorr.cxx:524)
==9587==    by 0x10438DE9: SvxAutoCorrect::AutoCorrect(SvxAutoCorrDoc&, String const&, unsigned short, unsigned short, unsigned char, Window*) (svxacorr.cxx:1418)
==9587==    by 0xFAA877F: SwEditShell::AutoCorrect(SvxAutoCorrect&, unsigned char, unsigned short) (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0xFEF8153: SwWrtShell::AutoCorrect(SvxAutoCorrect&, unsigned short) (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0xFE07339: ??? (in /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/lib/libswli.so)
==9587==    by 0x575EE83: ImplHandleKey(Window*, unsigned short, unsigned short, unsigned short, unsigned short, unsigned char) (in /data/opt/libreoffice/libreoffice-3-4/clone/libs-gui/vcl/unxlngi6.pro/lib/libvclli.so)

etc. :-)
Comment 10 Nicolas R 2011-06-07 09:22:24 UTC
(In reply to comment #7)
> DRAW also is affected and it seems that also options "Add non breaking ..." and
> "Format ordinal numbers" in 'Tools > Autocorrect > Localized Options' have to
> be checked as condition for the crash.

In my case, some strange behaviours when playing with autocorrect options / recovery mode ( yes, sometimes it's ok for five minutes when you're in "recovery", and crash immediatly if it's a brand new session without initial recovery).

But, following your clue ... It seems I've found one " almost always" reproducible crash / workaround in 
' Tools -> Autocorrect -> Localized Option -> Format ordinal numbers suffixes 1st 1^st' (the second and last localized option in my configuration).

If this option is unchecked : no crash
If this options is checked : 99% crash
Comment 11 Nicolas R 2011-06-07 09:27:52 UTC
Changed 'LibO 3.4 RC2' to 'LibO 3.4.0 release' ( not found this option when I created the bug report - but not tested with 3.4 Beta or RC).
Comment 12 Michael Meeks 2011-06-07 09:58:17 UTC
Fix pushed to master, waiting for review for 3.4.1 - should be done in plenty of time for that, thanks for the report ! :-)
And yes - great isolation, the bug was indeed in the ordinal suffix code.
Comment 13 vitriol 2011-06-08 07:56:09 UTC
*** Bug 38077 has been marked as a duplicate of this bug. ***
Comment 14 Nicolas R 2011-06-08 13:06:45 UTC
wow ... quick fix ! cheers !
Comment 15 Rainer Bielefeld Retired 2011-06-28 04:23:45 UTC
*** Bug 38736 has been marked as a duplicate of this bug. ***