Bug 36524 - EDITING: Delete Index causes crash
Summary: EDITING: Delete Index causes crash
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 Beta2
Hardware: x86-64 (AMD64) Windows (All)
: high critical
Assignee: Cédric Bosdonnat
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mab3.4
  Show dependency tree / graph
 
Reported: 2011-04-23 04:54 UTC by Rainer Bielefeld Retired
Modified: 2011-05-13 06:49 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-04-23 04:54:03 UTC 
"LibreOffice 3.4Beta2  – WIN7  Home Premium  (64bit) German UI [DEV300m103 (Build:1)]" crashes when I try to delete a Table of contents.

Steps tor reproduce:
1. Start LibO
2. Open new WRITER document from Start Center
3. Menu 'Insert > Indexes and Tables > Indexes and Tables - Table of contents'
   empty index with only heading will be inserted.
4. Click into heading
   Caret flickers behind heading text
5. Right click > 'Delete Index'
   Expected: TOC will be deleted
   Actual: Caret jumps aoutside TOC, but TOC remains
6. Mouse click into TOC
   CRASH
Comment 1 vitriol 2011-04-23 05:18:11 UTC 
I confirm. Crash and regression from 3.3.2
Comment 2 Rainer Bielefeld Retired 2011-04-23 23:43:13 UTC 
Due to Comment 1 NEW

@Cédric:
Your area?
Comment 3 vitriol 2011-05-07 02:53:25 UTC 
Changed as blocker. Crash/freeze in very basic and common functionality. 3.4 should not released with this bug for me.
Comment 4 Duncan Lithgow 2011-05-09 06:04:38 UTC 
Seen this too, reported at bug 36957, they may be related, see also bug 36340
Comment 5 Michael Meeks 2011-05-10 03:04:43 UTC 
Valgrind trace of master (as of now) - with debuginfo for writer, I guess we corrupt the document structure nastily somehow:

==6565== Use of uninitialised value of size 4
==6565==    at 0x102FBB81: BigPtrArray::Index2Block(unsigned long) const (bparr.cxx:197)
==6565==    by 0x102FB9C6: BigPtrArray::operator[](unsigned long) const (bparr.cxx:145)
==6565==    by 0x102B9AE3: SwNodes::operator[](unsigned long) const (ndarr.hxx:142)
==6565==    by 0x104BB127: SwEditShell::GetCurAttr(SfxItemSet&, bool) const (edattr.cxx:136)
==6565==    by 0x104C07ED: SwEditShell::GetCurCharFmt() const (edfmt.cxx:70)
==6565==    by 0x109B6C12: SwDocShell::StateStyleSheet(SfxItemSet&, SwWrtShell*) (docst.cxx:144)
==6565==    by 0x10AAD924: SwBaseShell::StateStyle(SfxItemSet&) (basesh.cxx:1817)
==6565==    by 0x10AA6F83: SfxStubSwBaseShellStateStyle(SfxShell*, SfxItemSet&) (swslots.hxx:1622)
==6565==    by 0x4838714: SfxDispatcher::_FillState(SfxSlotServer const&, SfxItemSet&, SfxSlot const*) (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x48338A4: ??? (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x48345EC: ??? (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x5627088: Link::Call(void*) const (link.hxx:140)
==6565== 
==6565== Invalid read of size 4
==6565==    at 0x102FBB81: BigPtrArray::Index2Block(unsigned long) const (bparr.cxx:197)
==6565==    by 0x102FB9C6: BigPtrArray::operator[](unsigned long) const (bparr.cxx:145)
==6565==    by 0x102B9AE3: SwNodes::operator[](unsigned long) const (ndarr.hxx:142)
==6565==    by 0x104BB127: SwEditShell::GetCurAttr(SfxItemSet&, bool) const (edattr.cxx:136)
==6565==    by 0x104C07ED: SwEditShell::GetCurCharFmt() const (edfmt.cxx:70)
==6565==    by 0x109B6C12: SwDocShell::StateStyleSheet(SfxItemSet&, SwWrtShell*) (docst.cxx:144)
==6565==    by 0x10AAD924: SwBaseShell::StateStyle(SfxItemSet&) (basesh.cxx:1817)
==6565==    by 0x10AA6F83: SfxStubSwBaseShellStateStyle(SfxShell*, SfxItemSet&) (swslots.hxx:1622)
==6565==    by 0x4838714: SfxDispatcher::_FillState(SfxSlotServer const&, SfxItemSet&, SfxSlot const*) (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x48338A4: ??? (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x48345EC: ??? (in /data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/lib/libsfxli.so)
==6565==    by 0x5627088: Link::Call(void*) const (link.hxx:140)
==6565==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

HTH.
Comment 6 Petr Mladek 2011-05-12 09:21:12 UTC 
A workaround is:

1. Right click > 'Delete Index'
   Expected: TOC will be deleted
   Actual: Caret jumps aoutside TOC, but TOC remains
2. Save document
3. File/Reload

Result: No crash, TOC is out.

Of course, this is ugly, not intuitive, ... On the other hand we have a workaround, TOC is used by more experienced users. They do not remove it that often => it would be nice to have a fix in 3.4.0 but it should not block this release for early adopters => reducing severity to critical
Comment 7 Rainer Bielefeld Retired 2011-05-12 09:43:34 UTC 
There never can be a workaround for crashes. The problem is not the inability to delete the TOC but the dataloss because of the crash. Fear to loose data with every key press IMHO is unacceptable for a user.
Comment 8 vitriol 2011-05-12 09:50:02 UTC 
(In reply to comment #7)
> There never can be a workaround for crashes. The problem is not the inability
> to delete the TOC but the dataloss because of the crash. Fear to loose data
> with every key press IMHO is unacceptable for a user.

+1
Comment 9 Cédric Bosdonnat 2011-05-13 00:24:48 UTC 
(In reply to comment #6)
> A workaround is:
> 
> 1. Right click > 'Delete Index'
>    Expected: TOC will be deleted
>    Actual: Caret jumps aoutside TOC, but TOC remains
> 2. Save document
> 3. File/Reload
> 
> Result: No crash, TOC is out.
> 
> Of course, this is ugly, not intuitive, ... On the other hand we have a
> workaround, TOC is used by more experienced users. They do not remove it that
> often => it would be nice to have a fix in 3.4.0 but it should not block this
> release for early adopters => reducing severity to critical

No need for a workaround, a patch fixing this crash has been sent for review to the dev mailing-list.