Download it now!
Bug 124162 - Crash when trying to accept changes
Summary: Crash when trying to accept changes
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: iOS Editor (show other bugs)
(earliest affected)
Hardware: Other iOS
: medium normal
Assignee: Henry Castro
Whiteboard: target:6.3.0 target:6.2.3
Depends on:
Blocks: Assert
  Show dependency treegraph
Reported: 2019-03-18 14:07 UTC by Nicolas Christener
Modified: 2019-03-24 23:04 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Video showing the crash (983.39 KB, video/mp4)
2019-03-18 14:13 UTC, Nicolas Christener
Example document which makes the crash reproducible (89.02 KB, application/vnd.oasis.opendocument.text-template)
2019-03-19 07:25 UTC, Nicolas Christener
Pre-edited sample (89.20 KB, application/vnd.oasis.opendocument.text)
2019-03-19 19:26 UTC, Aron Budea

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Christener 2019-03-18 14:07:21 UTC
In a document where some changes where recorded before, accepting all changes in most cases leads to a crash of the iOS app.

Steps to Reproduce:
1. Open/create a document in the iOS app
2. Record some changes
3. Accept the changes

Actual Results:
The app crashes in most of the cases.

Expected Results:
The changes should be accepted.

Reproducible: Always

User Profile Reset: No

Additional Info:
Comment 1 Nicolas Christener 2019-03-18 14:11:12 UTC
It seems, that this only happens, when a document with changes (done by the iOS) is opened and then one tries to accept the changes.
Comment 2 Nicolas Christener 2019-03-18 14:13:51 UTC
Created attachment 150061 [details]
Video showing the crash
Comment 3 Aron Budea 2019-03-18 23:08:55 UTC
I couldn't reproduce this crash myself, is it reproducible when starting from an empty document? (enabling track changes, making changes, reopening, accepting all changes)
Comment 4 Nicolas Christener 2019-03-19 07:25:09 UTC
Created attachment 150092 [details]
Example document which makes the crash reproducible

The attached document results to a crash in my case on 0.1 (22).

1.) Create a document from this template
You can use "" as template URL in the app settings and instantiate the document from there
2.) Enable change tracking
3.) Change "Rocky" to "Rock"
4.) Close the document
5.) Open the document
6.) Accept all changes
Comment 5 Tor Lillqvist 2019-03-19 12:15:51 UTC
I get a 404 for that URL. (And it needs to be https:// or iOS won't even let the code try to download the file.)
Comment 6 Nicolas Christener 2019-03-19 12:18:15 UTC
Sorry, should work again and https should be valid.
Comment 7 Tor Lillqvist 2019-03-19 12:35:17 UTC
Thanks, now I can reproduce. 

> Assertion failed: (*pIds > *(pIds-1)), function Invalidate, file /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/control/bindings.cxx, line 586.

> #4	0x0000000104a2580c in SfxBindings::Invalidate(unsigned short const*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/control/bindings.cxx:586
> #5	0x0000000106e37940 in SwView::Notify(SfxBroadcaster&, SfxHint const&) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sw/source/uibase/uiview/view.cxx:1703
> #6	0x0000000105114970 in SfxBroadcaster::Broadcast(SfxHint const&) at /Volumes/TML13/lo/ios-optimised-cp-6.0/svl/source/notify/SfxBroadcaster.cxx:49
> #7	0x0000000106bc6e00 in SwDocShell::Execute(SfxRequest&) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sw/source/uibase/app/docsh2.cxx:1331
> #8	0x0000000106bb1c80 in SfxStubSwDocShellExecute(SfxShell*, SfxRequest&) at /Volumes/TML13/lo/ios-optimised-cp-6.0/workdir/SdiTarget/sw/sdi/swslots.hxx:1385
> #9	0x0000000104a37e48 in SfxShell::CallExec(void (*)(SfxShell*, SfxRequest&), SfxRequest&) at /Volumes/TML13/lo/ios-optimised-cp-6.0/include/sfx2/shell.hxx:210
> #10	0x0000000104a37cbc in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/control/dispatch.cxx:361
> #11	0x0000000104a3e7e8 in SfxDispatcher::PostMsgHandler(SfxRequest*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/control/dispatch.cxx:1119
> #12	0x0000000104a384d8 in SfxDispatcher::LinkStubPostMsgHandler(void*, SfxRequest*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/control/dispatch.cxx:1099
> #13	0x0000000104cc2c94 in Link<SfxRequest*, void>::Call(SfxRequest*) const at /Volumes/TML13/lo/ios-optimised-cp-6.0/include/tools/link.hxx:84
> #14	0x0000000104cc2c40 in SfxHintPoster::DoEvent_Impl(void*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/notify/hintpost.cxx:44
> #15	0x0000000104cc2c04 in SfxHintPoster::LinkStubDoEvent_Impl(void*, void*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sfx2/source/notify/hintpost.cxx:42
> #16	0x0000000104ad72f0 in Link<void*, void>::Call(void*) const at /Volumes/TML13/lo/ios-optimised-cp-6.0/include/tools/link.hxx:84
> #17	0x00000001077881b0 in ImplHandleUserEvent(ImplSVEvent*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/window/winproc.cxx:1928
> #18	0x00000001077857c8 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/window/winproc.cxx:2478
> #19	0x0000000107ce2e34 in SalFrame::CallCallback(SalEvent, void const*) const at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/inc/salframe.hxx:275
> #20	0x0000000107ce82c4 in AquaSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/headless/svpinst.cxx:276
> #21	0x0000000107bc3d84 in SalUserEventList::DispatchUserEvents(bool) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/salusereventlist.cxx:109
> #22	0x0000000107ce8e98 in AquaSalInstance::DoYield(bool, bool) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/headless/svpinst.cxx:413
> #23	0x0000000107bf2e50 in ImplYield(bool, bool) at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/svapp.cxx:469
> #24	0x0000000107bf29bc in Application::Yield() at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/svapp.cxx:534
> #25	0x0000000107bf2938 in Application::Execute() at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/svapp.cxx:449
> #26	0x0000000104eec454 in desktop::Desktop::Main() at /Volumes/TML13/lo/ios-optimised-cp-6.0/desktop/source/app/app.cxx:1642
> #27	0x0000000107c03778 in ImplSVMain() at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/svmain.cxx:281
> #28	0x0000000107c060b8 in SVMain() at /Volumes/TML13/lo/ios-optimised-cp-6.0/vcl/source/app/svmain.cxx:319
> #29	0x0000000104f0d004 in ::soffice_main() at /Volumes/TML13/lo/ios-optimised-cp-6.0/desktop/source/app/sofficemain.cxx:167
> #30	0x0000000104f6be40 in lo_startmain(void*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/desktop/source/lib/init.cxx:4371
> #31	0x00000001074224bc in osl_thread_start_Impl(void*) at /Volumes/TML13/lo/ios-optimised-cp-6.0/sal/osl/unx/thread.cxx:234
Comment 8 Tor Lillqvist 2019-03-19 13:34:35 UTC
Congratulations, this crash (assertion failure) happens also on desktop LibreOffice. At least on macOS. On Linux, it seems to get stuck in a loop.
Comment 9 Tor Lillqvist 2019-03-19 14:19:33 UTC
The hack on Linux is caused by a different root cause, see my comment from a moment ago in . That code is related to the XDG_* thingies which are Linux-only.
Comment 10 Tor Lillqvist 2019-03-19 14:19:44 UTC
hang, not hack.
Comment 11 Aron Budea 2019-03-19 19:26:34 UTC
Created attachment 150109 [details]
Pre-edited sample

Attaching a pre-edited sample, the changes only need to be accepted via Edit -> Track Changes -> Accept all.
Comment 12 Aron Budea 2019-03-19 19:35:01 UTC
In Linux I get an assertion failure in a debug build, with the same message as Tor's in comment 7 (no crash otherwise). Interestingly there's no assertion if the button is clicked in the Manage Changes dialog.

The menu item was added in the following commit, but I don't know what the difference might be compared to the button. Henry, does the assert ring any bells to you?
author		Henry Castro <>	2017-11-04 12:18:53 -0400
committer	Henry Castro <>	2017-11-08 04:28:01 +0100

sw lok: add Accept/Reject All tracked changes, tdf#101977
Comment 13 Henry Castro 2019-03-19 19:54:49 UTC

I can reproduce it, working...
Comment 14 Henry Castro 2019-03-19 20:23:36 UTC

Would you please verify to merge master after build success?
Comment 15 Commit Notification 2019-03-19 22:29:06 UTC
Henry Castro committed a patch related to this issue.
It has been pushed to "master":

tdf#124162: Crash when trying to accept changes

It will be available in 6.3.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2019-03-20 04:23:10 UTC
Henry Castro committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

tdf#124162: Crash when trying to accept changes

It will be available in 6.2.3.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 17 Tor Lillqvist 2019-03-20 08:22:18 UTC
Should now be fixed in all relevant branches, including cp-6.0 from which the iOS app that Nicolas uses is built. Nicolas, please resolve once you get the next build of the app and have verified.
Comment 18 Nicolas Christener 2019-03-20 08:53:49 UTC
Thanks to all involved persons! I do very much appreciate the support and help to get those things fixed!

Will test the next release and keep my fingers crossed until then!

I wish you all a nice day!

Comment 19 Tor Lillqvist 2019-03-20 16:03:56 UTC
Nicolas, please mark as verified when you have eventually verified that the bug is gone.
Comment 20 Nicolas Christener 2019-03-21 07:58:48 UTC
Fixed in 0.1 (23).

Thanks a lot @Collabora
Comment 21 Aron Budea 2019-03-21 23:14:47 UTC
Let's use verified status, thanks for retesting Nicolas!