Bug 123042 - Right-click Delete All Comments crashes LibreOffice in Mac
Summary: Right-click Delete All Comments crashes LibreOffice in Mac
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.7.3 release
Hardware: All Mac OS X (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2019-01-29 19:50 UTC by dkistner
Modified: 2019-04-19 12:45 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
File that causes crash when "Delete all comments" is attempted. (79.71 KB, application/vnd.oasis.opendocument.text)
2019-01-30 23:08 UTC, dkistner
Details
Backtrace from lldb (5.34 KB, text/plain)
2019-02-06 08:54 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dkistner 2019-01-29 19:50:05 UTC
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:
Comment 1 Julien Nabet 2019-01-30 09:32:06 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this.

Could you give a try to 6.1.4?
Comment 2 dkistner 2019-01-30 18:33:06 UTC
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.
Comment 3 Xisco Faulí 2019-01-30 22:52:26 UTC Comment hidden (obsolete)
Comment 4 dkistner 2019-01-30 23:08:37 UTC
Created attachment 148783 [details]
File that causes crash when "Delete all comments" is attempted.
Comment 5 dkistner 2019-01-30 23:09:57 UTC
This also occurs in 6.1.4 on Mac Mojave.
Comment 6 Alex Thurgood 2019-02-06 08:29:45 UTC
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
Comment 7 Alex Thurgood 2019-02-06 08:33:45 UTC
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.
Comment 8 Alex Thurgood 2019-02-06 08:38:56 UTC
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.
Comment 9 Alex Thurgood 2019-02-06 08:46:28 UTC
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%
Comment 10 Alex Thurgood 2019-02-06 08:50:52 UTC
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)
Comment 11 Alex Thurgood 2019-02-06 08:54:12 UTC
Created attachment 148944 [details]
Backtrace from lldb

See enclosed bt from lldb session FWIW.
Comment 12 Tomaz Vajngerl 2019-04-19 05:33:01 UTC
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.
Comment 13 Xisco Faulí 2019-04-19 12:45:33 UTC
(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