When create a new style, and apply it to some words, then undo it (Ctrl+Z) all, and redo it(Ctrl+Y) all, you can find the style you create is lost, it maybe show in the list, but the style and formatting is lost, it become normal. Steps to reproduce: 1. New Writer 2. Type something 3. Open Style and Formatting dialog 4. Create a new style 5. Apply this style to the words you type in step 2 6. Press Ctrl+Z until you can't do it 7. Press Ctrl+Y until you can't do it You can find, the style you create has losted it's style and formatting. OS: Windows 8.1 Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: zh_CN This bug was first filed in the Chinese LibreOffice discussion forum: http://www.libreofficechina.org/thread-817-1-1.html somebody says in 4.3.2.1, the custom style is ok, but the words lost it's styles.
Hi yanlingtao, thanks for filing the issue. It works fine more me on Ubuntu with 4.4.0.2 So sorry that I cannot confirm the problem.
Hi Cor, What formats defines in your new style?I have defineed new font color and Outline in Font Effects page.
Hi yanlingtao, I defined font color and font size.
Hi all, I tested and find the following: 1. New Writer; 2. Create a new paragraph style (named "test") based on the default style, font color = blue. 3. Type in "abc" in your document, then apply style "test" to the text. 4. Undo until you can not undo. (I mean, undo all the steps, untill the "undo" toolbar icon is grayed out). 5. Redo untill you can not redo. (I mean, redo all the steps, untill the "redo" toolbar icon is grayed out). --> "abc" is in black color, while blue is expected. Aparently, by doing "undo" in step 4, * Firstly the applying of style "test" to text "abc" was undone; * Then the style attributes of "test" was undone; * Then the creation of style "test" was undone. However, by doing "redo" in step 5, * The creation of style "test" was redone, * But the style attributes of "test" was NOT redone (or was not redone correctly) * Also the applying of style "test" to text "abc" was not redone. Set to NEW Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: zh_CN
Now I can confirm this too. Maybe because in my previous test I started with typing, and then the creation of a style.
Bug still reproduciable with Version: 5.0.4.1 (x64) Build ID: 2def61bcbb29a7a8611b833682fe1291910b11ad Locale: zh-CN (zh_CN) Win10 x64
Still reproducible with: Version: 5.0.4.2 Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale: en-US (en.UTF-8) OS X 10.9
Version: 5.1.0.3 Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 2; OS Version: -; UI Render: default; Locale: en-US (en.UTF-8) OS X In this version, the test from Comment #3 effectively crashes Writer, and a document recovery dialog appears.
Crash backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000007a0008030 0x00007fff85e4bb22 in __dynamic_cast () (gdb) bt #0 0x00007fff85e4bb22 in __dynamic_cast () #1 0x00000001157518a3 in SwUndoFormatAttr::IsFormatInDoc () #2 0x00000001157516c7 in SwUndoFormatAttr::UndoImpl () #3 0x000000011575e2a6 in SwUndo::RedoWithContext () #4 0x0000000101349915 in SfxUndoManager::ImplRedo () #5 0x000000011574af9a in sw::UndoManager::impl_DoUndoRedo () #6 0x000000011574b17e in sw::UndoManager::Redo () #7 0x000000011553a47c in SwEditShell::Redo () #8 0x0000000115c2f94e in SwWrtShell::Do () #9 0x0000000115b05e39 in SwBaseShell::ExecUndo () #10 0x0000000100d12408 in SfxDispatcher::Call_Impl () #11 0x0000000100d0d39c in SfxBindings::Execute_Impl () #12 0x0000000100d457fc in SfxDispatchController_Impl::dispatch () #13 0x0000000100d43f27 in SfxOfficeDispatch::dispatch () #14 0x0000000101f8e4a2 in svt::ToolboxController::execute () #15 0x0000000100f0a8e6 in SfxToolBoxControl::execute () #16 0x0000000111ebcd6e in framework::ToolBarManager::Select () #17 0x0000000102a8485e in ToolBox::Select () #18 0x0000000102a93622 in ToolBox::ImplHandleMouseButtonUp () #19 0x0000000102a94ad3 in ToolBox::Tracking () #20 0x0000000102a9ba54 in vcl::Window::EndTracking () #21 0x0000000102ab16aa in ImplHandleMouseEvent () #22 0x0000000102ab3397 in ImplWindowFrameProc () #23 0x0000000102d7ef84 in -[SalFrameView sendMouseEventToFrame:button:eventtype:] () #24 0x00007fff8d392145 in -[NSWindow sendEvent:] () #25 0x00007fff8d3335d4 in -[NSApplication sendEvent:] () #26 0x0000000102d758c7 in -[VCL_NSApplication sendEvent:] () #27 0x0000000102d411b6 in AquaSalInstance::DoYield () #28 0x0000000102cce29e in Application::Yield () #29 0x0000000102cce238 in Application::Execute () #30 0x000000010007c7a2 in desktop::Desktop::Main () #31 0x0000000102cd2472 in ImplSVMain () #32 0x0000000102d40be4 in AquaSalInstance::handleAppDefinedEvent () #33 0x0000000102d758a4 in -[VCL_NSApplication sendEvent:] () #34 0x00007fff8d1839f9 in -[NSApplication run] () #35 0x00007fff8d16e783 in NSApplicationMain () #36 0x0000000102d3fef9 in ImplSVMainHook () #37 0x0000000102cd309a in SVMain () #38 0x00000001000a71b9 in soffice_main () #39 0x0000000100000f20 in main ()
Created attachment 127434 [details] backtrace master 5.3 from Windbg.txt
Still reproducible in Version: 5.4.0.0.alpha0+ Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18 Locale: es-ES (es_ES); Calc: group and Version: 5.4.0.0.alpha0+ Build ID: bd8c68c99cce51a3368d8ddfd6e11dccb72d8f49 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Created attachment 131532 [details] gdb backtrace
Crash introduced by: author Katarina Behrens <Katarina.Behrens@cib.de> 2015-05-03 21:25:52 (GMT) committer Katarina Behrens <Katarina.Behrens@cib.de> 2015-05-03 21:31:53 (GMT) commit 98436c4b53639d86f261ac630c46d32e3c7b8e28 (patch) tree be3be3fb1cdd44ad92c8a171ef72e00a96815be2 parent bc9d02b0ca6244b46c9e2c59b7cc3618eb0f0148 (diff) tdf#89783: Adjust to new GetPos retval (size_t vs. sal_uInt16) Some of the usages of GetPos were just misusing it to find out whether a vector contains given element -- use Contains() in those cases This patch is partially based on work of Christoph Lutz Adding Cc: to Katarina Behrens
Okay guys, I can make the crash go away, but I can't fix non-functional redo. I lack deeper knowledge of Writer to actually do that ... shall I do at least that?
Makes sense if crash is your regression from 5.0 and redo is some older problem from 4.4, like Bug 93045.
(In reply to Katarina Behrens (CIB) from comment #14) > Okay guys, I can make the crash go away, but I can't fix non-functional > redo. I lack deeper knowledge of Writer to actually do that ... shall I do > at least that? IMHO, we should make the crash go away despite of the fact the functionally doesn't work. Better to have a functionally not working than a crash
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1df637bde32c484b681ecdfebf56fdca03db7fc1 tdf#88555: band-aid fix, using GetPos/find instead of Contains It will be available in 5.4.0. 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.
regarding the crash, it is because commit 0f98299f7aa44bbb55c1bfeddca7799f727d14b0 inserted a dynamic_cast in the Contains function. Undo of the style creation deletes the SwFormat: #0 0x00007f08164adf1b in SwFormat::~SwFormat() (this=0x3d63770, __in_chrg=<optimized out>) at /work/lo/libreoffice-5-3/sw/source/core/attr/format.cxx:214 #1 0x00007f0816614874 in SwFormatColl::~SwFormatColl() (this=0x3d63770, __in_chrg=<optimized out>) at /work/lo/libreoffice-5-3/sw/inc/fmtcol.hxx:33 #2 0x00007f0816746f16 in SwTextFormatColl::~SwTextFormatColl() (this=0x3d63770, __in_chrg=<optimized out>) at /work/lo/libreoffice-5-3/sw/inc/fmtcol.hxx:54 #3 0x00007f0816746f32 in SwTextFormatColl::~SwTextFormatColl() (this=0x3d63770, __in_chrg=<optimized out>) at /work/lo/libreoffice-5-3/sw/inc/fmtcol.hxx:54 #4 0x00007f081660e8f5 in SwDoc::DelTextFormatColl(unsigned long, bool) (this=0x36cb7e0, nFormatColl=7, bBroadcast=true) at /work/lo/libreoffice-5-3/sw/source/core/doc/docfmt.cxx:991 #5 0x00007f081660ea11 in SwDoc::DelTextFormatColl(SwTextFormatColl*, bool) (this=0x36cb7e0, pColl=0x3d63770, bBroadcast=true) at /work/lo/libreoffice-5-3/sw/source/core/doc/docfmt.cxx:999 #6 0x00007f0816c98836 in SwUndoTextFormatCollCreate::Delete() (this=0x3d4f130) at /work/lo/libreoffice-5-3/sw/source/core/undo/SwUndoFmt.cxx:206 #7 0x00007f0816c97f77 in SwUndoFormatCreate::UndoImpl(sw::UndoRedoContext&) (this=0x3d4f130) at /work/lo/libreoffice-5-3/sw/source/core/undo/SwUndoFmt.cxx:63 the call to SwFormatsModifyBase::Contains effectively wants to check if the SwFormat has been deleted; i think every SwFormat is in some SwDoc member array for as long as it is alive. of course with the dynamic_cast in Contains, the check if it's still alive turns into use-after-free crash. the patch in commit #17 should fix this crash but every other call to Contains probably either crashes or is pointless because it will always return true.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7068a7d9b945e0c6d4965445b6d951038e9c987&h=libreoffice-5-3 tdf#88555: band-aid fix, using GetPos/find instead of Contains It will be available in 5.3.4. 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.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-3-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d866bb51927b8b75718438a63138834bb7ea2f6c&h=libreoffice-5-3-3 tdf#88555: band-aid fix, using GetPos/find instead of Contains It will be available in 5.3.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=01575a06725648188d51de90323a6f1da97ef7a9 tdf#88555 sw: remove dynamic_cast from SwFrameFormats::Contains It will be available in 5.4.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d31f114327e77c48c8cdc804e1e399ebeadd27c tdf#88555 sw: reduce usage of dynamic_cast in SwFormatsModifyBase::Contains It will be available in 5.4.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=91646b10315e2ee64b25fb8a604012c729343c07 tdf#88555 sw: use safe IsAlive function in Undo code It will be available in 5.4.0. 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.
Not easy to reproduce but I did per Comment 4, crash in 5.2 and formatting lost in 5.5.+. So, if crash was fixed, styles was not.
The crash issue is fixed. I split the lost of formatting to new bug report (bug 113640).
(In reply to Kevin Suo from comment #25) > The crash issue is fixed. I split the lost of formatting to new bug report > (bug 113640). Thanks Kevin!
setting to VERIFIED as per comment 25