Description: With the cursor inside a comment, attempting to delete all commments in the document results in the crash/recovery process. This happens with deleting all comments by one individual or all comments in the document. It has repeated six times in a row, so I think this is a bug. I was able to delete a single comment. Once crashed, the Start Recovery window is buried behind all other windows on the system. Steps to Reproduce: 1.Place cursor on comment 2.Right-click, Delete All Comments (or Delete All Commments by User) 3. Actual Results: Repeated crashes requiring recovery of document. Expected Results: Software should have deleted all comments in the document as requested. Reproducible: Always User Profile Reset: Yes Additional Info:
On pc Debian x86-64 with master sources updated today, I don't reproduce this. Could you give a try to 6.1.4?
This must be a Mac thing. I'm running MacOs Mojave 10.14.2. I installed LibreOffice 6.1.4, and it does the same thing. This is a file that has tracked changes from editing with comments. After I finish editing a document, I copy it to a master file and make accept all tracked changes, then delete all the comments. I can delete the comments one at a time with no problem, but when I attempt to delete all comments at once, or all comments made by just me, LO crashes.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 148783 [details] File that causes crash when "Delete all comments" is attempted.
This also occurs in 6.1.4 on Mac Mojave.
No repro with Version: 6.3.0.0.alpha0+ Build ID: e9db8eceff48290be72591f7422b4fc45e5752fc CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
With Version: 6.1.3.2 Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded the comments aren't deleted, even if I try several times, simply nothing happens, but there is no crash either.
However, with Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded I get a hang, and spinning beachball, requiring a forced kill. Will try and obtain some kind of trace.
This seems to be thread that the app hangs in : * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001813e9444 libswlo.dylib`SwUndo::FillSaveData(SwPaM const&, SwRedlineSaveDatas&, bool, bool) + 388 libswlo.dylib`SwUndo::FillSaveData: -> 0x1813e9444 <+388>: callq 0x180f9f8e0 ; SwPosition::operator<=(SwPosition const&) const 0x1813e9449 <+393>: testb %al, %al 0x1813e944b <+395>: movq %rbx, %rax 0x1813e944e <+398>: cmovneq %r13, %rax with the processor (as indicated via the system monitor utility) running at 100%
Hmm, see this too, if I let the process continue: Process 50602 resuming Process 50602 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001813e5ada libswlo.dylib`SwUndo::GetComment() const + 42 libswlo.dylib`SwUndo::GetComment: -> 0x1813e5ada <+42>: callq 0x1819a0d2a ; symbol stub for: rtl_uString_new 0x1813e5adf <+47>: cmpb $0x0, 0x25(%rbx) 0x1813e5ae3 <+51>: je 0x1813e5afb ; <+75> 0x1813e5ae5 <+53>: cmpb $0x0, 0x28(%rbx)
Created attachment 148944 [details] Backtrace from lldb See enclosed bt from lldb session FWIW.
Interesting - I can't reproduce this in the development branch for LibreOffice 6.2 and neither in master. I guess something fixed it and was already back-ported.
(In reply to Tomaz Vajngerl from comment #12) > Interesting - I can't reproduce this in the development branch for > LibreOffice 6.2 and neither in master. > > I guess something fixed it and was already back-ported. According to comment 6, Alex can't reproduce it in master either. Closing as RESOLVED WORKSFORME