Created attachment 65289 [details] Brief test preso that exhibits the problem on my system. The attached minimal presentation was originally created in LO 3.5.5 and I have been using it to test for an elusive crash bug when moving a slide to the top of the deck (it gets numbered Slide 0 and LO crashes). When I try to move any of the three slides in the attached presentation, the slide being moved changes to a copy of the first slide. Keep shuffling and random slide duplication happens. Makes LO 3.6 unsafe and unusable to me, hence Critical. Using OS X 3.6.8 on an 8Gb Macbook Pro.
Created attachment 65290 [details] Screen recording of the bug in action
On pc Debian x86-64, with master sources updated today, I reproduced the problem. I noticed that the slide with images and the slide "why I gave..." have the same name ("page 0"). If I rename 1 of them, it seems ok (quickly tested only). Could you give it a try ? QA/devs guys: now could we consider it a bug ? Perhaps a slide should have a internal name to avoid this kind of thing ?
(In reply to comment #2) > I noticed that the slide with images and the slide "why I gave..." have the > same name ("page 0"). If I rename 1 of them, it seems ok (quickly tested only). Note that I have not given any of the slides names; whatever names they have are auto-allocated by the software. I have noticed in the crash-bug I was trying to reproduce that the first slide ends up being numbered as Zero (the usual pattern for the crasher is I try to move a slide to the top of the deck, the top two slides get marked as zero, the system hangs for a bit as if there's a tight loop in LO and then the app crashes).
Do you mean you don't encounter the original problem once you renamed the slide ? If yes, could you tell how have you created each of the slides with same name ? Did you copy a slide from another impress file (perhaps also from a ppt file ?) With 3.5 branch, I tried this: - create a new file, it contains 1 slide (name "Slide 1") - copy paste the slide, I've got "Slide 1" and "Slide 2"
(In reply to comment #4) > Do you mean you don't encounter the original problem once you renamed the slide > ? No - I am saying I have not given any of the slides names so there is no name to "change". I tried allocating names to the slides and was indeed able to move them around safely. > If yes, could you tell how have you created each of the slides with same name ? I did not name any of the slides. Any names you find on them have been created by LO. > Did you copy a slide from another impress file (perhaps also from a ppt file ?) This demo deck was created by deleting most of the slides from the deck I used to create http://www.infoworld.com/slideshow/59811/7-reasons-googles-nexus-7-beats-the-ipad-199490 - that deck was created a few days earlier from scratch using an empty preso and no template. Most slides were created just using "Insert Slide" - no duplication as far as I recall. Anything that's happened to the file has been the result of a day or so of interaction through LO.
(In reply to comment #5) > (In reply to comment #4) > > Do you mean you don't encounter the original problem once you renamed the slide > > ? > > No - I am saying I have not given any of the slides names so there is no name > to "change". > > I tried allocating names to the slides and was indeed able to move them around > safely. > So the file is ok after renaming since you can move the slides safely. > > If yes, could you tell how have you created each of the slides with same name ? > > I did not name any of the slides. Any names you find on them have been created > by LO. > > > Did you copy a slide from another impress file (perhaps also from a ppt file ?) > > This demo deck was created by deleting most of the slides from the deck I used > to create > http://www.infoworld.com/slideshow/59811/7-reasons-googles-nexus-7-beats-the-ipad-199490 > - that deck was created a few days earlier from scratch using an empty preso > and no template. Most slides were created just using "Insert Slide" - no > duplication as far as I recall. Anything that's happened to the file has been > the result of a day or so of interaction through LO. I understand you didn't name any slide but one can't guess how you created this buggy file. So I put it as RESOLVED/WORKSFORME. If you know how to reproduce the problem, don't hesitate to reopen the bug.
(In reply to comment #6) > > I understand you didn't name any slide but one can't guess how you created this > buggy file. So I put it as RESOLVED/WORKSFORME. > > If you know how to reproduce the problem, don't hesitate to reopen the bug. The problem is with the SOFTWARE, not with the FILE. Despite the fact you have identified a workaround that avoids the problem after it has become manifest, the software still behaves incorrectly and the file supplied provides a test case for a developer to identify the fault in the software and correct it; you have confirmed that this file does indeed make the fault in the software reproducible. Moreover, this could be a path to fix an elusive crasher. Thus re-opened.
1) The FILE has a problem since 2 slides have same name. Except if LO considered OK to have the same name for 2 slides ? In this case, why can't I recreate this case from scratch with 3.5.4 Debian packages for example ? 2) The SOFT has a problem since it has been possible to generate a buggy file (without using anything else than LO < 3.5.5). So 1 problem with 2 aspects. Now you said you had a crash randomly but it was with the badly name slides. So it's probably due to the problem I indicated (except if you can reproduce a crash with rightly name slides) So except if you can reproduce the crash or reproduce how to have same names for slides. I don't know how to keep on with this tracker. Perhaps QA or dev guys will have some idea about this.
To be clear: I am reporting a problem that occurs with LO (both 3.5.5 and 3.6) which the attached file makes reproduceable. That problem is that, when slides are moved around, the content is incorrectly rendered on screen ("corrupted") as per the video I supplied and as you have also reproduced on Linux. It is a cross-platform software problem that needs fixing and now we have the attached .ODP it's likely it can be identified and fixed. In my report, I also indicated this reproducible problem was discovered as part of my efforts to create a valid bug report for another problem where LO crashes. This crasher has existed for years but I have never been able to put it in a bottle so it can be fixed. Still working on it.
Radek - slide sorter crasher from Simon - any chance you could have a look ? :-) sounds nasty.
@Simon Phipps: Is’t this (more or less) the same issue as in bug 51023? Please check if it is the same (data corruption, and eventually a crash) as bug 51023 ... Thank you very much!
Looks like it is, yes. Note that the attached preso file appears to exhibit the issue on Linux too...
Appears to be a duplicate, yes - note the test file allegedly exhibits the bug on Linux. *** This bug has been marked as a duplicate of bug 51023 ***
@ Simon Phipps: Thank you very much for testing this! And it is very interesting if this is also reproducible on Linux, too ... Platform changed accordingly. @ Michael Meeks: Seems that this is (now = bug 51023) an important issue, and, as Simon says, not limited to Mac OS. Any chance that our Impress experts could take a look at it, or that Tor which his new Mac OS debug build (used for bug 47368) could try to analyse bug 51023? Would be wonderful ...