Bug 34548 - EDITING: CRASH in action after Undo
Summary: EDITING: CRASH in action after Undo
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: high critical
Assignee: David Tardon
URL:
Whiteboard: target:4.1.0 target:4.0.1 target:3.6.6
Keywords: haveBacktrace
: 60786 60787 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2011-02-21 15:55 UTC by canscabh
Modified: 2013-05-17 11:19 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug 34548 - WinDbg session with FAILED_SOURCE_CODE (24.41 KB, text/plain)
2012-06-06 04:55 UTC, bfoman (inactive)
Details
bt + console logs on master sources (7.49 KB, text/plain)
2012-08-18 17:05 UTC, Julien Nabet
Details
valgrind logs (37.07 KB, application/x-gzip)
2012-09-06 21:32 UTC, Julien Nabet
Details
cleaner log (16.24 KB, text/plain)
2012-09-07 09:27 UTC, Michael Meeks
Details
valgrind log with more frames (31.16 KB, text/plain)
2012-09-07 10:07 UTC, Michael Meeks
Details
horrible hack-around ... (735 bytes, patch)
2012-09-07 11:40 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description canscabh 2011-02-21 15:55:41 UTC
To reproduce this error, do the following steps:

1. Open Impress
2. Create a new "Empty presentation" with the "Presentation Wizard"
3. Add some text on the title slide in the Text Frame (where it says "Click to add text")
4. deselect the Text Frame 
5. select the Text Frame and delete it
6. Undo as much as possible 
	BUG1(The text will not reappear)
7. Click in the Text Frame so that you get a cursor to enter text
8. Click somewhere beside the Text Frame and LibreOffice will crash
	BUG2(CRASH)
Because the second bug is likely caused by the first, we filed just a single bug report.
We were able to reproduce this with 3.3.0 on both Win7_64 and Ubuntu 10.10 x64 and 3.3.1 RC2 on Win7_64.
Comment 1 Rainer Bielefeld Retired 2011-02-21 21:53:36 UTC
Crash is [Reproducible] with "LibreOffice 3.3.1 RC2 – WIN7  Home Premium  (64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]"

No problem with OOo3.4-dev

This is a really serious problem

@Thorsten:
Can you help?
Comment 2 Jorendc 2011-02-22 02:29:56 UTC
Reproducible with "LibreOffice 3.3.1 RC2 – Mac OSX 10.6.6 Dutch UI"
Comment 3 digital ant 2011-03-18 19:41:05 UTC
confirmed OSX 10.5.0_28, LibO 3.3.2 rc2, Apple jre 1.5.0_8
confirmed on Windows XP sp3 build 2600, LibO 3.3.2 rc2 and jre 1.6.0_24
Comment 4 digital ant 2011-03-18 19:48:17 UTC
confirmed on Ubuntu 10.10 x32, LibO 3.3.1 (330m19 Build:8), jre 1.6.0_20
Comment 5 Mihkel Tõnnov 2011-09-29 13:41:46 UTC
Still present in LibreOffice 3.4.3. Confirmed on Debian Lenny and Windows XP Pro (both 32-bit).

I also tried to reproduce it on OOo 3.4 series early dev-snapshot, and the bug is present there as well.
Comment 6 K.M. 2011-11-02 06:37:56 UTC
With LO 3.4.4rc2 (LibreOffice 3.4.4, OOO340m1 (Build:402)) I can reproduce the behavior of step 6 of the description called "BUG 1".

However, I cannot reproduce the crash mentioned in step 8.
Comment 7 Rainer Bielefeld Retired 2011-11-02 06:56:08 UTC
Modified Version: <http://wiki.documentfoundation.org/BugReport_Details#Version>

Both problems still  [Reproducible] with "LibreOffice 3.4.4RC1  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:401)]" 

Both problems still [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]" (110909)

I wonder why I didn't see the problem with 3.4-dev :-/
Comment 8 Cyril 2011-12-17 06:22:27 UTC
Crash still [Reproducible] with "LibreOffice 3.4.4 OOO340m1 (build:402)" under Linux Mageia 1 (32 bits) French UI.
Comment 9 Thorsten Behrens (CIB) 2011-12-20 07:34:52 UTC
still occurs with 3.5.0 Beta1
Comment 10 pierre-yves samyn 2012-03-08 04:34:34 UTC
Hello

Another (easy) way to reproduce :

1. File> New> Presentation> Empty presentation> Create  (same problem with an existing one)
2. View > Outline
3. Type something (A for instance)
4. Edit> Undo (or Ctrl+Z)

Actual result : apparently nothing
Expected result : undo insert

5. Enter => Crash

Reproduced (fr-discuss) with :
- Ubuntu 11.10 - LibO 3.4.5
- Win XP SP3 - LibO 3.4.5 
- Win XP SP3 - LibO 3.5.0

Not reproduced with Ubuntu 11.04 avec LibO 3.3.x 

Regards
Pierre-Yves
Comment 11 Renato Mendes 2012-03-19 15:04:53 UTC
Reproduced - Win XP SP3 - LibO 3.4.5
Comment 12 Rainer Bielefeld Retired 2012-03-19 23:58:03 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 13 Florian Reisinger 2012-03-25 07:19:52 UTC
See the comment before mine, I changed the version
Comment 14 Christopher M. Penalver 2012-03-25 07:23:36 UTC
Florian Reisinger, please do not toggle the version. For more on this please see: http://wiki.documentfoundation.org/BugReport_Details#Version
Comment 15 Rainer Bielefeld Retired 2012-04-01 10:46:35 UTC
3.4 lifecycle is terminated, so shift to “Bug 37361 LibreOffice 3.5 most annoying bugs”, because still reproducible in 3.5 (see comments) and still [Reproducible] with parallel  installation of  Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 3ddf85d-6299bf6-879ce3]" (tinderbox: Win-x86@6-fast pull time 2012-03-30 00:06:13)
Comment 16 Cor Nouws 2012-04-15 08:06:24 UTC
(In reply to comment #10)
> Another (easy) way to reproduce :
> 
> 4. Edit> Undo (or Ctrl+Z)
> 
> Actual result : apparently nothing
> Expected result : undo insert
> 
> 5. Enter => Crash
> 
> Not reproduced with Ubuntu 11.04 avec LibO 3.3.x 

I cannot reproduce this with 3.5.2 and master from 2012-04-10 on Ununtu 11:04.
However, I sometimes have strange crashes, so can immagine that the sequence of the original bug report does lead to a crash
Comment 17 canscabh 2012-04-15 08:33:17 UTC
I can no longer reproduce the crash using 3.5.1.2 with the original steps.
I have found another way to make it crash:

between steps 7. and 8. you have to enter some text and it will still crash.

As I don't seem to be able to edit my original report, can a mod do this?
Comment 18 dE 2012-04-20 02:22:25 UTC
This issue still exists, but has new and very different issues with the original steps.
Comment 19 tommy27 2012-05-14 15:54:02 UTC
reproduced with LibO 3.5.3 on Windows Vista 64bit following this sequence (see Comment 1 and Comment 17)

To reproduce this error, do the following steps:

1. Open Impress
2. Create a new "Empty presentation" with the "Presentation Wizard"
3. Add some text on the title slide in the Text Frame (where it says "Click to
add text")
4. deselect the Text Frame 
5. select the Text Frame and delete it
6. Undo as much as possible 
    BUG1(The text will not reappear)
7. Click in the Text Frame so that you get a cursor to enter text and enter keys
8. Click somewhere beside the Text Frame and LibreOffice will crash
    BUG2(CRASH)
Comment 20 bfoman (inactive) 2012-06-06 04:55:02 UTC
Created attachment 62668 [details]
Bug 34548 - WinDbg session with FAILED_SOURCE_CODE

Confirmed with:
LO 3.5.4.2 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Crash as per comment 19.
Attached full WinDbg session with FAILED_SOURCE_CODE.
The same FAULTING_SOURCE_CODE as in bug 37580.
Comment 21 Michael Meeks 2012-06-25 04:02:18 UTC
Radek any thoughts ? seems embarrassingly easy to reproduce - it'd be wonderful to have a unit test for this as/when we fix it I guess. There is also a nice stack-trace for windows towards the end of the previous attachment :-)
Comment 22 pierre-yves samyn 2012-07-09 07:16:53 UTC
Hello

IMHO the reproduction of the bug is difficult to describe because of the necessary selections-deselections.

Below is a simpler procedure to reproduce with version 3.5 or Version 3.6.0.0.beta3 (Build ID: 3e2b862)

1. File> New> Presentation
2. Add some text in the Text Frame (where it says "Click to add title")
3. Deselect the Text Frame (for example click on "Click to add text")
4. Select the Title Text Frame (blue squares) and delete it 
5. Undo
6. In the Task pane, try to change something, Layout, Master page...

Crash 

Regards
Pierre-Yves
Comment 23 Rainer Bielefeld Retired 2012-07-09 07:50:55 UTC
Reproducible] with Server Installation of  "LibreOffice 3.6.0.0.beta3  German UI/Locale [Build-ID: 3e2b862] on German WIN7 Home Premium (64bit) 

Steps how to reproduce (Similar Comment 22)

1. Button  'New Presentation' from LibO Start Center
2. Add some text in the Title Frame (where it says "Click to add title")
3. Deselect the Text Frame (for example click on "Click to add text")
4. Select the Title Text Frame (blue squares) and delete it 
   Unexpected: New frame "Insert Title" appears
5. Menu 'Edit ->Undo'
   > Old Title Frame appears additional to "Insert Title"
6. In the Task pane -> Select item Master page -> Select "Vintage"
   > Crash 

I also reproduce Problems with 3.3.3, but there the crash appears not before a step 7 (for example: Close -> Discard)
Comment 24 Julien Nabet 2012-08-18 17:05:05 UTC
Created attachment 65741 [details]
bt + console logs on master sources

On pc Debian x86-64 with master sources (future 3.7) updated today.
I reproduced the problem by following the Rainer's process (comment 23).

I noticed a log:
warn:legacy.tools:18086:1:/home/julien/compile-libreoffice/libo/svx/source/svdraw/svdundo.cxx:771: UndoInsertObj: RemoveObjNum!=pObj
Comment 25 Michael Meeks 2012-09-06 14:25:11 UTC
Any chance of a valgrind trace [ the debugging symbols are helpful - but valgrind should be even sweeter ;-],
Comment 26 Julien Nabet 2012-09-06 21:32:32 UTC
Created attachment 66752 [details]
valgrind logs

On pc Debian x86-64 with master sources updated today, I still reproduce the problem.
So I tried to retrieve a valgrind log but I don't know if it contains the crash.

I noticed the line 14601:
 ==10034==  Address 0x21b86020 is 8 bytes after a block of size 8 alloc'd

Michael: is it useful or do you want me to try again?

Remark:
I used http://wiki.documentfoundation.org/BugReport#How_to_get_strace_log_.28on_Linux.29 + no limit for errors so it gave this line for the calling:
valgrind --tool=memcheck --num-callers=50 --error-limit=no --trace-children=yes ./soffice.bin --impress 2>&1 | tee ~/tmp/valgrind
Comment 27 Michael Meeks 2012-09-07 09:21:16 UTC
Lovely - thanks so much for that Julien - very helpful. You can see the mess that Java makes in the trace (be nice to turn that off somehow I guess if it's possible). Sadly the Python garbage collector also produces a huge mass of false positives as well [ I guess disabling / deleting *py*.so in program/ might help ;-].

Seemingly the trace also doesn't show the crash - did you manage to get it to crash under valgrind ? it seems like the attached trace stops in the middle somehow (which is odd). I'd expect the trace to end:

==13539== 
==13539== HEAP SUMMARY:
==13539==     in use at exit: 64,093 bytes in 342 blocks
==13539==   total heap usage: 764 allocs, 422 frees, 154,216 bytes allocated

and some more lines :-)

Any chance you can re-try having disabled java and clobbered python ? :-)
Comment 28 Michael Meeks 2012-09-07 09:24:54 UTC
I'm just being a lamer - this is easy to reproduce here; I'll poke at it...
Comment 29 Michael Meeks 2012-09-07 09:27:29 UTC
Created attachment 66770 [details]
cleaner log
Comment 30 Michael Meeks 2012-09-07 10:07:54 UTC
Created attachment 66772 [details]
valgrind log with more frames
Comment 31 Michael Meeks 2012-09-07 10:13:26 UTC
It -looks- like the undo action itself is the broken bit - which appears not to remove the object from the slide itself leaving it owned by the SfxListUndoAction and also linked to in the slide. Switching the master-page just clears the undo queue and forces the crash sooner (that would otherwise happen potentially much latter when it fell off the bottom of the undo queue). What a nice bug ! :-)
Comment 32 Michael Meeks 2012-09-07 10:21:56 UTC
Looks like the SdrUndoInsertObj is the problem, impress creates a derived class
SdrUndoNewObj : public SdrUndoInsertObj from CreateUndoNewObject:

#0  SdrUndoFactory::CreateUndoNewObject (this=0x95c4c08, rObject=..., bOrdNumDirect=false)
    at /ssd/opt/libreoffice/master/svx/source/svdraw/svdundo.cxx:1703
#1  0xaef76cae in SdPage::CreatePresObj (this=0x9630a98, eObjKind=PRESOBJ_TITLE, bVertical=0 '\000', rRect=...)
    at /ssd/opt/libreoffice/master/sd/source/core/sdpage.cxx:545
#2  0xaef77e29 in SdPage::InsertAutoLayoutShape (this=0x9630a98, pObj=0x0, eObjKind=PRESOBJ_TITLE, bVertical=false, aRect=..., bInit=true)
    at /ssd/opt/libreoffice/master/sd/source/core/sdpage.cxx:2192
#3  0xaf13b12d in sd::DrawView::DeleteMarked (this=0x96f8118) at /ssd/opt/libreoffice/master/sd/source/ui/view/drawview.cxx:626
#4  0xaf03876a in sd::FuDraw::KeyInput (this=0x9d15a58, rKEvt=...) at /ssd/opt/libreoffice/master/sd/source/ui/func/fudraw.cxx:443

I assume the lifecycle gets woolly there.
Comment 33 Michael Meeks 2012-09-07 11:23:05 UTC
I'm suspicious of the: svdundo.cxx /SdrUndoInsertObj::Undo/ method - I imagine it is removing a different object than the one it is intended to do (which explains why the main text box in the body disappears, instead of the header on undo ;-) - an off-by-one as it were. With this debugging patch:

--- a/svx/source/svdraw/svdundo.cxx
+++ b/svx/source/svdraw/svdundo.cxx
@@ -759,17 +759,17 @@ void SdrUndoInsertObj::Undo()
     // Trigger PageChangeCall
     ImpShowPageOfThisObject();
 
-    DBG_ASSERT(pObj->IsInserted(),"UndoInsertObj: pObj is not inserted.");
     if (pObj->IsInserted())
     {
         ImplUnmarkObject( pObj );
 
-#ifdef DBG_UTIL
         SdrObject* pChkObj=
-#endif
         pObjList->RemoveObject(nOrdNum);
-        DBG_ASSERT(pChkObj==pObj,"UndoInsertObj: RemoveObjNum!=pObj");
-    }
+
+        fprintf (stderr, "UndoInsertObj: RemoveObjNum %p == pObj %p ordinal %d vs %d\n",
+                 pChkObj, pObj, (int)nOrdNum, (int)pObj->GetOrdNum());
+    } else
+        fprintf (stderr, "not inserted !\n");
 }
 
 void SdrUndoInsertObj::Redo()

I get:

UndoInsertObj: RemoveObjNum 0x969d9d8 == pObj 0x9d47390 ordinal 2 vs 0

Which explains the bad behaviour.

Quite -how- this undo list is supposed to keep it's nOrdNum synchronised with whatever is going on in the sdpage is -totally- opaque to me; the whole thing looks crazy from a lifecycle perspective.

It's deeply unclear to me that all this referencing by ordinal is at all sensible - particularly vs. having a reference-counted object handle to an immutable object.

It'd be great to have a translation of GetOrdNum vs. GetOrdNumDirect in svx/inc/svx/svdobj.hxx - to try to grok what's going on there - if there is a German speaker around.
Comment 34 Michael Meeks 2012-09-07 11:40:31 UTC
Created attachment 66782 [details]
horrible hack-around ...

This is an horrible band-aid, it stops the crash - but ... it's hard to live with oneself here. Clearly the arithmetic is going -badly- wrong here, for some reason - and the code looks glass-fragile all about the place ;-)

OTOH the band-aid can't make things worse (or can it - by potentially forcing a re-ordering of the dirtied ordering in the svdpage - urgh).
Comment 35 K.M. 2012-09-07 12:31:22 UTC
(In reply to comment #33)

> It'd be great to have a translation of GetOrdNum vs. GetOrdNumDirect in
> svx/inc/svx/svdobj.hxx - to try to grok what's going on there - if there is a
> German speaker around.

// Ueber die Objekt-Ordnungsnummer kann man feststellen, ob ein Objekt vor
// oder hinter einem anderen liegt. Objekte mit kleinen Ordnungsnummern werden
// zuerst gezeichnet, Objekte mit grossen Ordnungsnummern zuletzt.
// Wird die Reihenfolge der Objekte in der Liste veraendert, so wird ein
// Dirty-Flag gesetzt (an der Page). Beim naechsten SdrObject::GetOrdNum()
// werden die Ordnungsnummer aller Objekte der Liste neu bestimmt.

Via the object ordinal number it is possible to find out if an object is in front or behind another object. Objects with lower ordinal numbers will be drawn first, objects with higher ordinal numbers last. If the order of the objects in the list is changed, a dirty-flag is set (on the Page). During the next call of SdrObject::GetOrdNum() the ordinal numbers of all objects of the list will be re-calculated/set.

sal_uInt32 GetOrdNum() const;

// Diese Methode sollte nur verwendet werden, wenn man ganz  genau weiss,
// was man macht:

This method SHOULD only be used if you know very well, what you do:

sal_uInt32 GetOrdNumDirect() const { return nOrdNum; }
Comment 36 Michael Meeks 2012-10-04 15:08:29 UTC
It would be great to have a bibsect investigation on this one - then again - it is a really early issue:

> Crash is [Reproducible] with "LibreOffice 3.3.1 RC2 – WIN7  Home Premium
> (64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]"

That's pretty horrible; so somewhere really early in our launch history I guess.
Comment 37 ydutrieux 2012-12-14 15:49:49 UTC
Reproduced with Lib 4.0 Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)

nb : I have to clic more than once beside the frame to cause the crash.

Yves
Comment 38 Joel Madero 2013-02-11 15:56:03 UTC
Indeed, still an issue. 

Version 4.1.0.0.alpha0+ (Build ID: 80cbc04c2cbe25ebdfe2f22bb2e5ba62728e963)

Bodhi Linux

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

LibreOffice 3.5 is at the end of life for its release cycle so we are going to move this to 3.6 MAB so we can close the 3.5 MAB bug. Apologies that the problem still persists, I will get in touch with David to see if he's had some time to investigate. If not, we'll try to find another developer to tackle this.

Thanks for your patience, understanding and clear instructions. Very annoying bug indeed
Comment 39 tommy27 2013-02-13 09:09:36 UTC
@Joel
should we reopen this bug?
Comment 40 Rainer Bielefeld Retired 2013-02-13 09:51:42 UTC
The problem is that we do not have any information with what commit this problem has been solved for what version

My results with server installation of  "Version 4.1.0.0.alpha0+ (Build ID: bdfd8de57bf5767ce5c179a5e8705c7587f7b32) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-06_22:06:22" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with own separate User Profile:

Original report crash: reproducible
Comment 10 crash: No longer reproducible (and imho very different thing)
Comment 19 crash: Still reproducible
Comment 22 crash: Still reproducible
Comment 23 crash: Still reproducible (only more precise description of
                  proceeding due to comment 20

I would prefer to mark this one as WFM becauss Fix is unknown, but to avoid lots of mails because of MAB relation I will wait few days, may be we can get commit info.

@Michael, David
Can you contribute commit information?

@tommy27
I answer for Joel: no, we should not reopen this one. This Bug report has become rather unclear, it's unknown what has been fixed ....

If I can reproduce my results with latest Master I will report new bugs for crashes due to Comments 19 / 22 (and may be C 10) to avoid any "hodgepodge", please wait some moments.

@Joel:
Please cite the complete LibO/About info (it's so easy). Only the version code is rather useless, most of us can't find out the pull time info with it.
Comment 41 Jorendc 2013-02-13 10:16:53 UTC
I think we have: http://cgit.freedesktop.org/libreoffice/core/commit/?id=e462a30d03c16aa4202f8d28ad52b15feb3d9255

but due a typo in the title (bug 34558 instead of bug 34548) the message and target is now placed over there (I'll delete it).

Therefore is RESOLVED FIXED a correct status

Kind regards,
Joren
Comment 42 Michael Meeks 2013-02-13 11:15:52 UTC
It'd be great to back-port David's fix to -4-0 - better I guess would be a systematic fix of this kind of undo problem in impress and an understanding of where these indicees started to go wrong, why we regressed here & better some unit tests but ... ;-) since David's working on it - I fully expect an excellent solution.
Comment 43 Rainer Bielefeld Retired 2013-02-13 11:22:41 UTC
My planned tests will come a little later because of Bug 60782.

@Jorendc 
Thank you for additional info
Comment 44 Rainer Bielefeld Retired 2013-02-13 12:36:59 UTC
I submitted:
"Bug 60786 - EDITING: CRASH after Edit Textbox after Undo"
"Bug 60787 - EDITING: CRASH When insert master page from Task Pane after Undo"
Comment 45 David Tardon 2013-02-14 05:55:47 UTC
Michael pointed out that the fix causes crashes in couple of unoapi tests -> it needs revision.
Comment 46 Not Assigned 2013-02-15 06:36:53 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=115054fef08998c56cba8f14472df1d15007f635

fdo#34548 don't crash on undoing text frame removal



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 47 David Tardon 2013-02-15 13:52:31 UTC
*** Bug 60786 has been marked as a duplicate of this bug. ***
Comment 48 David Tardon 2013-02-15 13:58:20 UTC
*** Bug 60787 has been marked as a duplicate of this bug. ***
Comment 49 Not Assigned 2013-02-19 09:45:46 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3432c63c0cdcdfe3e74702c16ce6c746d9c0fdf4&h=libreoffice-4-0

fdo#34548 don't crash on undoing text frame removal


It will be available in LibreOffice 4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 50 Not Assigned 2013-02-19 12:11:58 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=156d6552ce70ed387668d20e9000b5e725bda45f&h=libreoffice-3-6

fdo#34548 don't crash on undoing text frame removal


It will be available in LibreOffice 3.6.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 51 Pierre C 2013-03-21 20:03:23 UTC
Thanks, it works fine in 3.6.6.1
Comment 52 pierre-yves samyn 2013-04-21 07:16:49 UTC
Hello

WORKSFORME with Windows 7 64bits &
Version 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39)

Thank you
Regards
Pierre-Yves