Apache OpenOffice (AOO) Bugzilla – Issue 105710
Crash in numbering bullets dialog in impress after copy&paste
Last modified: 2017-05-20 10:28:59 UTC
One of my users experiences this crash quite often. I have had trouble reproducing it but he does much more work on presentations then me (and this basically stops him from working). Basically when working on an Impress file (usually big files), with many bullets and numbering on every page he keeps clicking on the bullets and numbering button and eventually OO will crash. Relevant IDs: rbusndc ru2r9dc rp3wgdc This bug occurs on Ubuntu with Ubuntu's 3.0.1 (Jaunty) and Ubuntu's 3.1.1 (Karmic). The IDs above are when I had official Sun's 3.1.1 manually installed on Jaunty.
Reassigned. Anything visible from the stacks?
Created attachment 65233 [details] Test file
Steps to reproduce: 1. Copy any line that starts with a letter (h,i,j,k) 2. Paste it somewhere else (everywhere I tried including on the same slide) 3. Click Bullets/Numbering Button
wg - are you asking me? How would I get access to the submitted stacktraces and/or create them from an Ubuntu version?
cl->gquigs: never mind, he is asking me :) The first one is a stack during switching the slides but not visible what happens. The other two crashes during executing a dialog but it is not visible which one cl->wg: the stacks are useless and I can't reproduce the crash with the bullet numbering button. Can you? I tried m60 on windows
Sorry, still no reproducible here. I have tried m60, 3.1, 3.1.1 on two different linux platforms and could not get a crash. Anyone else?
Created attachment 65279 [details] OpenOffice config - should extract to .openoffice.org
The attached config should increase the chances of the crash happening. I'm going to go through and see if I can create such a bad config in a reproducible way.
New steps (you can ignore the previous config attachment): 1. Open a blank Impress document 2. Switch to title/text layout 3. Make the first text line numbering type 1,2,3 and customize position to start at 2 4. Type in something to copy later - I used "cheese" 5. Hit enter 6. On line 2 turn off bulleting 7. Hit enter and on line 3 turn it back on 8. Same numbering type, but put the customize position at 5 9. Write "not cheese" on line 3 10. Hit enter 11. Copy cheese on to line 4. 12. Hit bullets and numbering and hopefully enjoy a nice crash. There might be a faster way to do this, but I'm hoping this is at least reproducible.
Test in latest OOo-dev 3.2, new ID: rx3nudc Shorter way to reproduce: 1. Create slide with numbering on it, setting the Start At position manually. 2. Write text in the slide. 3. Copy the text to another slide (or pretty much anywhere else) 4. Hit the Bullets/Numbering button (and enjoy the crash) Thanks!
Oh, I have enjoyed it ;-) This one works reliable. Reassigned. Already in 3.0.
When we cut and paste text which has a SvxNumBulletItem on it then we are still using SfxItemPool::Store and SfxItemPool::Load and there is no implementation of SvxNumBulletItem::Load/Store anymore so we get the default item, the default item has 0 levels in it and nothing in the dialogs etc. is set up to survive that.
Created attachment 66035 [details] re-introduce load/store for SvxNumBulletItem and friends
right, so if I put back the Load/Store impls and friends then crash be gone. Not 100% sure of course if that Load/Store implementation is now fully in sync with the features of the numbering class, but it definitely is a massive improvement over losing numbering information when pasting from one slide to another in impress and crashing when using the numbering dialog on them
cl->cmc: your observations are correct. Impress/Draw still use the binary format for text clipboard operations so removing them was an error from the writer team. Evaluating if this is a showstopper...
talked with wg about it, we both agreed to vote this issue as a showstopper for OOo 3.2 target as it is clearly a regression and it is a crash during regular work with impress
adapting summary
fixed in cws impress183 for OOo 3.2 cl->cmc: your patch was fine, the only think missing was initialization of the newly introduced members mePositionAndSpaceMode, meLabelFollowedBy, mnListtabPos, mnFirstLineIndent, mnIndentAt in SvxNumberFormat::SvxNumberFormat(SvStream &rStream). You basically fixed the crash by restoring a numbering item with random behavior :-) But that's just FYI, your work saved me a lot of time.
@wg: Please verify.
Verified in CWS.
*** Issue 98770 has been marked as a duplicate of this issue. ***
*** Issue 107303 has been marked as a duplicate of this issue. ***