How to reproduce: - Start an empty presentation - add some text - Change the bullets of this text (main menu: Format->Bullets and Numbering) - Copy this text to a new line - Notice that the bulleting style is not copied along with the text - Try and restore the bullets of the copied text (main menu: Format->Bullets and Numbering) Expected behaviour: - Any bullet or numbering can be applied to the copied text Actual behaviour: - No bullet or numbering can be applied to the copied text - Changing tabs in the Bullets and Numbering dialog crashes Impress (!) Conclusion: Copying text in Impress with non default bulleting corrupts the presentation. Note that the corruption is persistent: - Saving the file and reloading it does not restore the corrupted document or prevent the crash. - Setting the bulleting back to the default does not not restore the corrupted document or prevent the crash. It does not matter what kind of bullets are chosen. Problem appears in: - Open Office 3.1.0 on Windows XP - Open Office 3.2.1 on Windows XP - Open Office Portable 3.1.0 on openSuSE 11.4 / wine 1.3.37 - Open Office 3.3.0 on openSuSE 11.4 / wine 1.3.37 - Libre Office Portable 3.4.3 on openSuSE 11.4 / wine 1.3.37 - Libre Office 3.4.4.3 from OBS Stable op openSuSE 11.4 - Libre Office Portable 3.5.0 on openSuSE 11.4 / wine 1.3.37
On pc Debian x86-64, with 3.5 branch, I reproduce what is described except the crash. On console, I noticed these logs : warn:legacy.tools:7757:1:/home/julien/compile-libreoffice/libo_3_5/editeng/source/editeng/impedit5.cxx:246: UndoAction SelectionMarker? warn:legacy.tools:7757:1:/home/julien/compile-libreoffice/libo_3_5/editeng/source/editeng/editeng.cxx:1807: MarkInvalid: End out of Range! The second line is repeated each time I try to apply bullets for original or copied line. Here are the lines of the function : 1803 void EditEngine::QuickMarkInvalid( const ESelection& rSel ) 1804 { 1805 DBG_CHKTHIS( EditEngine, 0 ); 1806 DBG_ASSERT( rSel.nStartPara < pImpEditEngine->GetEditDoc().Count(), "MarkInvalid: Start out of Range!" ); 1807 DBG_ASSERT( rSel.nEndPara < pImpEditEngine->GetEditDoc().Count(), "MarkInvalid: End out of Range!" ); 1808 for ( sal_uInt16 nPara = rSel.nStartPara; nPara <= rSel.nEndPara; nPara++ ) 1809 { 1810 ParaPortion* pPortion = pImpEditEngine->GetParaPortions().SaveGetObject( nPara ); 1811 if ( pPortion ) 1812 pPortion->MarkSelectionInvalid( 0, pPortion->GetNode()->Len() ); 1813 } 1814 } I didn't test on master cause it's recompiling for the moment.
Created attachment 58278 [details] Error log produced by LO impress after the crash
After installing the debuginfo packages for LO on my system, crashing impress as originally described produces the following error message on the command line: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x8133c744, pid=21532, tid=3027945168 # # JRE version: 6.0_24-b24 # Java VM: OpenJDK Client VM (20.0-b12 mixed mode linux-x86 ) # Derivative: IcedTea6 1.11.1 # Distribution: Dummy Product (i586), package suse-0.3.2-i386 # Problematic frame: # C [libcuili.so+0x1d1744] SvxRelativeField::EnableRelativeMode(unsigned short, unsigned short, unsigned short)+0x1d1744 # # An error report file with more information is saved as: # /home/stephan/hs_err_pid21532.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # [error occurred during error reporting , id 0xb] The error report file is attached under number 58278
I didn't reproduce this on master too (commit : c604a738f48ffa4c12f7c9801d03a146303d3123) but had the same errors as on 3.5 branch. Some questions : - since you seem having tested different LO/OOo versions, could you remove/backup your LO profile (~/.config/libreoffice and/or ~/.libreoffice, check both) + OOo profile (~/.config/openoffice and/or ~/.openoffice, check both again) - could you install libreoffice-dbg to have more info ? - why do you give your Wine version ?
Hi Julien: Removed both ~/.config/libreoffice and ~/.libreoffice like you suggested in comment #4. ~/.config/openoffice and ~/.openoffice are not present. Installed all available libreoffice-*-debuginfo packages. AFAIK these are the openSuSE equivalents of libreoffice-dbg in the Debian world. The re-bulleting still doesn't work. The crashes still occur. Note that in step 6 I have to switch to another tab like "Position" in the "Bullets and Numbering" dialog immediately after choosing the bullets to make Impress crash. These crashes are very reproducible on my system when Impress is started from the KDE GUI. They are however much less frequent when Impress is started from the command line. The results on Windows XP and wine suggest that the problem is not specific to KDE. The wine version is given whenever a test was performed on a linux system with a Windows LO/OO executable. The wine version installed is not the default version for OpenSuSE 11.4.
Hi Julien, Running impress from within gdb: stephan@Joule2:/usr/lib/libreoffice/program> gdb ./soffice.bin Results in Program received signal SIGSEGV, Segmentation fault. SvxNumPositionTabPage::InitControls (this=0x80d3f738) at /usr/src/debug/libreoffice-bootstrap-3.4.4.3/src/libreoffice-components-3.4.4.3/cui/source/tabpages/numpages.cxx:2911 2911 if(aNumFmtArr[nLvl]->GetNumAdjust() == SVX_ADJUST_LEFT) At the crash moment. Hope it helps find the problem.
I finally reproduced your pb with master (updated today). Your comment 5 helped me. Now I'm gonna try to understand what's happening precisely with gdb.
Created attachment 62500 [details] Bug 47018 - 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 when clicked Position tab. Bulleting doesn't work. Attached full WinDbg session with FAILED_SOURCE_CODE.
Same type of problem fixed here ? http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9fb24e17fcf72b08e90b4b243f1aa927fd97689
Ivan Timofeev committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=66b86df5736e84888e2e6d54079e4adef819bbb5 related to fdo#47018: fix DBG_ASSERT in EditEngine::QuickMarkInvalid 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.
(In reply to comment #10) > Ivan Timofeev committed a patch related to this issue. just fixed "MarkInvalid: End out of Range!" from Comment 1...
Just tested with Version 4.1.0.0.alpha0+ (Build ID: d2f57b6c1275e0e6ed7f214d471ddb84ecb1b4a), (Did "./g pull -r ; make" ca. 4 hours after these commits) Problem is still present.
I have been investigating the cause of this crash for some time now, and these are my findings so far: The immediate cause of the crash is in file: /cui/source/tabpages/numpages.cxx method: SvxNumOptionsTabPage::InitControls() This method is called every time the user opens the numbering options tab page. In this method the local variable nLvl is used as an index into local variable aNumFmtArr[SVX_MAX_NUM], a vector of pointers. On valid input: SvxNumOptionsTabPage::pActNum->GetLevelCount() = 10 in a for-loop the local variable sal_uInt16 nLvl is set to the 0-based index of the Numbering Level chosen by the user On invalid input (after the botched copying of a bulleted text line, see my OP) SvxNumOptionsTabPage::pActNum->GetLevelCount() = 0 the for-loop is skipped: nLvl = USHRT_MAX (= initialisation value) nLvl is then used as an index into local variable aNumFmtArr[SVX_MAX_NUM], a vector of pointers. On my home system: SVX_MAX_NUM = 10 USHRT_MAX = 65535 USHRT_MAX >> SVX_MAX_NUM, so LibreOffice segfaults because of the out-of-bounds index. Maybe SvxNumOptionsTabPage::InitControls() could be adapted to allow for this kind of invalid input by doing some kind of range check, but that is not what I propose. I want to find the real cause of this invalid input, and that is in the code that does the copying and pasting. More on that in a later post.
Created attachment 76621 [details] console + bt with symbols on master sources On pc Debian x86-64 with master sources updated today, I reproduced the crash so attached bt + console logs. (the bullet isn't copied too) I noticed this: warn:legacy.osl:27742:1:cui/source/tabpages/numpages.cxx:2813: cannot happen
Thorsten/Radek: one for you?
I added some trace to display nLvl and its value is 65535 so it corresponds perfectly to Stephan's findings.
*** Bug 62887 has been marked as a duplicate of this bug. ***
Cao Cuong Ngo committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5785db93c5739846fb0a84b138be485044d4bda5 fdo#47018 Impress crashes when modifying bullet 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.
Cao Cuong Ngo committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f504b6307179f00075bd1dadd722ff2e8855ea9&h=libreoffice-4-0 fdo#47018 Impress crashes when modifying bullet It will be available in LibreOffice 4.0.3. 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.
Just tested with Version: 4.1.0.0.alpha0+ Build ID: a28a70cdd6a3a28f902f153f725da3bae042c18 on Ubuntu 12.04 (32-bits), (after ./g pull -r; make clean; make; make dev-install) Issue is NOT fixed. The crash is prevented, but bullets are not copied along with text. Setting status to Reopened. I tested a patch from gerrit: Change-Id: I57d1245db650d12e6b2c05baece379038b673689, see https://gerrit.libreoffice.org/#/c/3352/ a couple of days ago that did fix this issue completely. It has apparently been abandoned in favour of another patch. Testing patch set 3 from https://gerrit.libreoffice.org/#/c/3369/ To see if it fixes this issue.
Patch 3369 set 3 fixes bullet and numbering but not Bitmap bullet. Set 4 will fixes the Bitmap issue ;) CC Ngo.
@CC Ngo: Just tested patch set 3 on 4.1 master. I see what you mean. I'll test with patch set 4 now. I see you don't touch numpages.cxx in these patches. Any plans for that?
In fact I misunderstood :-), all numbering and bullets are SvxNumBulletItem now So we only need to change numitem.cxx. I made an error in converting bullet char in set 2 and bitmap object in set 3. With set 4 everything is working fine now :) Hope that helps, CCN.
Tested patch 4 from https://gerrit.libreoffice.org/#/c/3369/ on master. Bullets, numbering and graphics are all copied nicely with this patch.
Cao Cuong Ngo committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a95cce27295f9cd255fa72eaded00972e3efb69b fix fdo#47018 Impress paste destroy bullet 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.
Tested with Version: 4.1.0.0.alpha0+ Build ID: a95cce27295f9cd255fa72eaded00972e3efb69 on openSuSE 11.4 (64-bit) Problem is indeed fixed. Thanks to all involved. It has been a hard nut to crack!
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98d594abd42c5aa33d6981f4dd19582c2d345705 Revert "fix fdo#47018 Impress paste destroy bullet" 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.
I had to revert the fix for now, see comment 27.
Indeed, that was an unnecessary change anyway. I made a new patch https://gerrit.libreoffice.org/#/c/3479/
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=721d0dfe70323d31e26394cfb32056a7ceec96c7 Revert "Revert "fix fdo#47018 Impress paste destroy bullet"" 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.
OK we can close this thing now!
(In reply to comment #30) > Eike Rathke committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=721d0dfe70323d31e26394cfb32056a7ceec96c7 > > Revert "Revert "fix fdo#47018 Impress paste destroy bullet"" Does this need backporting from master to libreoffice-4-0 (where the original commit had not been reverted)?
(In reply to comment #32) > Does this need backporting from master to libreoffice-4-0 (where the > original commit had not been reverted)? That original commit is not on 4-0, only the first one fixing the crash is.
Tested with Version: 4.1.0.0.alpha0+ Build ID: e7a5f5ef80c3e66101cfb063cbed0527c055931 on Ubuntu 12.04 (32-bit). Problem is indeed fixed (again). Standing by with wooden stakes in case this bug rises from the grave again....
*** Bug 59914 has been marked as a duplicate of this bug. ***