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.
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?
Reproducible with "LibreOffice 3.3.1 RC2 – Mac OSX 10.6.6 Dutch UI"
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
confirmed on Ubuntu 10.10 x32, LibO 3.3.1 (330m19 Build:8), jre 1.6.0_20
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.
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.
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 :-/
Crash still [Reproducible] with "LibreOffice 3.4.4 OOO340m1 (build:402)" under Linux Mageia 1 (32 bits) French UI.
still occurs with 3.5.0 Beta1
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
Reproduced - Win XP SP3 - LibO 3.4.5
<http://wiki.documentfoundation.org/BugReport_Details#Version>
See the comment before mine, I changed the version
Florian Reisinger, please do not toggle the version. For more on this please see: http://wiki.documentfoundation.org/BugReport_Details#Version
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)
(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
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?
This issue still exists, but has new and very different issues with the original steps.
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)
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.
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 :-)
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
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)
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
Any chance of a valgrind trace [ the debugging symbols are helpful - but valgrind should be even sweeter ;-],
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
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 ? :-)
I'm just being a lamer - this is easy to reproduce here; I'll poke at it...
Created attachment 66770 [details] cleaner log
Created attachment 66772 [details] valgrind log with more frames
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 ! :-)
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.
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.
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).
(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; }
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.
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
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
@Joel should we reopen this bug?
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.
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
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.
My planned tests will come a little later because of Bug 60782. @Jorendc Thank you for additional info
I submitted: "Bug 60786 - EDITING: CRASH after Edit Textbox after Undo" "Bug 60787 - EDITING: CRASH When insert master page from Task Pane after Undo"
Michael pointed out that the fix causes crashes in couple of unoapi tests -> it needs revision.
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.
*** Bug 60786 has been marked as a duplicate of this bug. ***
*** Bug 60787 has been marked as a duplicate of this bug. ***
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.
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.
Thanks, it works fine in 3.6.6.1
Hello WORKSFORME with Windows 7 64bits & Version 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39) Thank you Regards Pierre-Yves