Hello, When I do undo with multi-windows Draw crash. Not with new document. Here the crash report: http://crashreport.libreoffice.org/stats/crash_details/cf3772aa-5999-4ca8-a0c0-0412cc9c80d4 I can send you document crashing in private.
Hello, Thanks for reporting this bug. Could you please try to sanitize the document as described here: https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
No need I found a way to crash. 1. Create a new draw document. 2. Create a new text area with some text (Text1) 3. Create a new page 4. Open a new window (Win2) 5. In Win1 select Page1 and in Win2, Page2. 6. In Win1 select the text (let the text area opened) 7. In Win2 do something then undo (Ctrl-Z) Draw crash... In same time, if you only create 1 page the text area disappear in Win2. Draw crash only if Win1 and Win2 have not the same page activated.
I'm not able to reproduce with the steps given in comment 2 Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
Confirmed in Versió: 6.0.0.0.alpha0+ ID de la construcció: 0342c5e8086c8200ecadbe9d52dd4ef6a093effb CPU threads: 4; OS: Linux 4.10; UI render: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group and in Versión: 5.4.0.3 Id. de compilación: 7556cbc6811c9d992f4064ab9287069087d7f62c Subproc. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group http://crashreport.libreoffice.org/stats/crash_details/0abca439-57e6-478c-a72f-fabbdf143288
Confirmed in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e but not in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Same behaviour in Impress: 1. Create a new impress document. 2. Create a new text area with some text (Text1) 3. Create a new slide 4. Window - New Window (Win2) 5. In Win1 select Page1 and in Win2, Page2. 6. In Win1 select the text (let the text area opened) 7. In Win2 do something then undo (Ctrl-Z) Impress crash...
Repro with Version: 6.1.0.0.alpha0+ Build ID: ea89dabf8b6363972190a6b50c527c418d51c2c7 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-01-27_22:55:15 Locale: nl-NL (nl_NL); Calc: CL
Bibisected with Linux 42max, it had one skipped commit at the end (refused to run Impress), so it gave these two candidates (which are related anyway): commit 33535c4b8815ba7ccd2e84767933d92ae00e8b4f Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 21:46:38 2015 +0800 source-hash-ee8fad644e28d1e298afb7c6eed4d454617e7dc7 commit ee8fad644e28d1e298afb7c6eed4d454617e7dc7 Author: Kohei Yoshida <kohei.yoshida@collabora.com> AuthorDate: Mon Oct 7 13:07:28 2013 -0400 Commit: Kohei Yoshida <kohei.yoshida@collabora.com> CommitDate: Tue Oct 8 15:44:34 2013 -0400 ContentInfo to store svl::SharedString instead of OUString. commit a232a7698b6c2bff53f61cad2c025fb932c5a9be Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 21:46:41 2015 +0800 source-hash-658fc68d574bd49b8b233ad5ed886758e290b3aa commit 658fc68d574bd49b8b233ad5ed886758e290b3aa Author: Kohei Yoshida <kohei.yoshida@collabora.com> AuthorDate: Mon Oct 7 17:27:02 2013 -0400 Commit: Kohei Yoshida <kohei.yoshida@collabora.com> CommitDate: Tue Oct 8 15:48:10 2013 -0400 Store svl::SharedString in document cell storage instead of OUString. With this, both ScColumn and ScMatrix store svl::SharedString as their string values, instead of OUString.
I'll try to take a look at this, let's see if I get anywhere.
Created attachment 151920 [details] Reproducer document. With this document, the reproducer steps are shorter: 1) Open the document and create a second window. 2) Have slide 1 on window 1, slide 2 on window 2. 3) Start text edit on window 1. 3) Move the shape on window 2 & undo -> assertion failure while SdrUndoMoveObj::Undo() is on the stack.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3a874f1c80c37e8b35666e1d73161ff762eb7e4c%5E%21 tdf#111522 svx: fix crash with view1 doing text edit and view2 doing sdr undo It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This resolves the shape insert and shape move cases. Let's close this; if there are other shape actions where this is a problem, those can be handled in separate bugs. Thanks.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/79dbe90d5efce44881a82161cf91a63fdef5d109%5E%21 tdf#111522 svx: fix crash with view1 doing text edit and view2 doing sdr undo It will be available in 6.3.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Miklos Vajna from comment #10) > Created attachment 151920 [details] > Reproducer document. > > With this document, the reproducer steps are shorter: > > 1) Open the document and create a second window. > > 2) Have slide 1 on window 1, slide 2 on window 2. > > 3) Start text edit on window 1. > > 3) Move the shape on window 2 & undo -> assertion failure while > SdrUndoMoveObj::Undo() is on the stack. Verified in Version: 6.3.0.0.beta1+ Build ID: cabaadf278ba099c53ed2b7a32f1e11bc632ad3a CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Miklos, thanks for fixing this issue!! OTOH, it crashes if instead of moving the drawing it's resized or rotated. @Miklos, I'm wondering, should the same 'const bool bUndo = IsUndoEnabled() && CanDoSdrUndo();' check be added to the other 'const bool bUndo = IsUndoEnabled();' in svx/source/svdraw/svdedtv1.cxx ??
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/9870ff897f088563426bee9567dd9cb722c2b929%5E%21 Related: tdf#111522 svx: fix crash with view1 doing textedit and resize/rotate It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/79cae65f4725d0a8abd5639dc298002d11b2626c%5E%21 Related: tdf#111522 svx: fix crash with view1 doing textedit and resize/rotate It will be available in 6.3.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/2980fa249a2680f32915de470a9cd8840780c2a0%5E%21 tdf#111522 svx: fix crash with view1 doing text edit and view2 doing sdr undo It will be available in 6.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Xisco Faulí from comment #14) > OTOH, it crashes if instead of moving the drawing it's resized or rotated. > @Miklos, I'm wondering, should the same 'const bool bUndo = IsUndoEnabled() > && CanDoSdrUndo();' check be added to the other 'const bool bUndo = > IsUndoEnabled();' in svx/source/svdraw/svdedtv1.cxx ?? Verified in Version: 6.4.0.0.alpha0+ Build ID: ec905d131374f0860bac77c52873eed984b1966f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Miklos, thanks for the second fix!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/507771e499cf3ea658781d4e044ea4400888e3a6%5E%21 Related: tdf#111522 svx: fix crash with view1 doing textedit and resize/rotate It will be available in 6.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm the user: Ron Larkin on 20230308 at about 1250 CST. The essence of my 22030308 mid-day crash may be a thread or process conflict such as a semaphore failure, priority issue, or failure to trash a thread properly. The Details page points to "mutex", which confirms that guess. I was using LibreOffice Calc on a several-page table. The crux may be that I was in the middle of correcting spelling of multiple terms and, without completing the correcting, edited a couple (?) of cells to correct other errors I noticed. If the spell corrector and the editor are not fully "aware" of each others' actions, the stack could easily have been corrupted by using them both in different ways. The table has no arithmetic or chart that could be involved in a malf; I was using Calc simply because it is handy for creating a table standalone without the rest of LibreOffice. I believe I have seen this same crash before but did not connect it to the way I was working with the table. I'm an experienced C++ programmer in a very different real-time context, not that the code I was running was necessarily C++... Ron Larkin
(In reply to Ron Larkin from comment #20) > I'm the user: Ron Larkin on 20230308 at about 1250 CST. > The essence of my 22030308 mid-day crash may be a thread or process conflict > such as a semaphore failure, priority issue, or failure to trash a thread > properly. The Details page points to "mutex", which confirms that guess. > I was using LibreOffice Calc on a several-page table. The crux may be that > I was in the middle of correcting spelling of multiple terms and, without > completing the correcting, edited a couple (?) of cells to correct other > errors I noticed. If the spell corrector and the editor are not fully > "aware" of each others' actions, the stack could easily have been corrupted > by using them both in different ways. The table has no arithmetic or chart > that could be involved in a malf; I was using Calc simply because it is > handy for creating a table standalone without the rest of LibreOffice. > I believe I have seen this same crash before but did not connect it to > the way I was working with the table. > I'm an experienced C++ programmer in a very different real-time context, > not that the code I was running was necessarily C++... This crash was fixed years ago, so you probably want to create a new report for your crash.