Steps to reproduce: 1. Open attached document 2. Select all 3. Edit->Track Changes->Comment -> Crash reproduced in Version: 6.4.0.0.alpha0+ Build ID: d62f6b7d40284b2e41831376e5388711ab6250f3 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
Created attachment 152560 [details] sample document
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9cb5b06eea8f0067bb9ddee9f4f1c992eda34a64 author László Németh <nemeth@numbertext.org> 2019-01-31 14:27:06 +0100 committer László Németh <nemeth@numbertext.org> 2019-01-31 18:41:59 +0100 commit 9cb5b06eea8f0067bb9ddee9f4f1c992eda34a64 (patch) tree c07a1c95ae086d9b645b88796c0f27b8219c1359 parent 50b14658ec0ba6ccd7799a314143f3405d7036b3 (diff) tdf#79197 enable comment of a selected change Bisected with bibisect-linux64-6.3 Adding Cc: to László Németh
Created attachment 152568 [details] bt with debug symbols (gtk3) On pc Debian x86-64 with master sources updated today, I could reproduce this.
My bibisected commit allowed only commenting at whole selection of the tracked change, but the real problem were introduced before that. Please, repeat the bibisecting with the following modification: 1. Open attached document 2. Select the first letter of the change *from left to right* 3. Edit->Track Changes->Comment sometimes LO doesn't crash, but mostly does it.
(In reply to László Németh from comment #4) > My bibisected commit allowed only commenting at whole selection of the > tracked change, but the real problem were introduced before that. > > Please, repeat the bibisecting with the following modification: > > 1. Open attached document > 2. Select the first letter of the change *from left to right* > 3. Edit->Track Changes->Comment > > sometimes LO doesn't crash, but mostly does it. I can reproduce this crash in bibisect-win32-6.0 : Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: GL; Locale: hu-HU (hu_HU); Calc: CL Looking further...
(In reply to László Németh from comment #4) > My bibisected commit allowed only commenting at whole selection of the > tracked change, but the real problem were introduced before that. > > Please, repeat the bibisecting with the following modification: > > 1. Open attached document > 2. Select the first letter of the change *from left to right* > 3. Edit->Track Changes->Comment > > sometimes LO doesn't crash, but mostly does it. ok, you're right. so I find it crashes with older versions with 1. Open attached document 2. Select the first letter of the change *from left to right* 3. Edit->Track Changes->Comment 4. Click on cancel
Introduced at some point in LibreOffice 4.2. The bisection points me to https://cgit.freedesktop.org/libreoffice/core/commit/?id=b8002169336b6b7597d32755e41fa3dc2688539e, which is incorrect, see https://bugs.documentfoundation.org/show_bug.cgi?id=119241#c8, so the problem was introduced around that point... Lowering severity...
(In reply to Xisco Faulí from comment #7) > Introduced at some point in LibreOffice 4.2. The bisection points me to > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=b8002169336b6b7597d32755e41fa3dc2688539e, which is incorrect, see > https://bugs.documentfoundation.org/show_bug.cgi?id=119241#c8, so the > problem was introduced around that point... > > Lowering severity... I could crash even 4.0 but not 3.6 :)
here's the valgrind trace of where things go wrong... ==31190== Invalid read of size 8 ==31190== at 0x33D102CC: SwBaseShell::GetView() (basesh.hxx:57) ==31190== by 0x33EAC8D1: SwTextShell::ExecField(SfxRequest&) (textfld.cxx:549) ==31190== by 0x33EB30A0: SfxStubSwTextShellExecField(SfxShell*, SfxRequest&) (swslots.hxx:2999) ==31190== by 0x7130EAF: SfxShell::CallExec(void (*)(SfxShell*, SfxRequest&), SfxRequest&) (shell.hxx:197) ==31190== by 0x7127F25: SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) (dispatch.cxx:356) ==31190== by 0x712B7CF: SfxDispatcher::PostMsgHandler(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >) (dispatch.cxx:1093) ==31190== by 0x71514E9: void std::__invoke_impl<void, void (SfxDispatcher::*&)(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), SfxDispatcher*&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> > >(std::__invoke_memfun_deref, void (SfxDispatcher::*&)(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), SfxDispatcher*&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&) (invoke.h:73) ==31190== by 0x714D7B8: std::__invoke_result<void (SfxDispatcher::*&)(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), SfxDispatcher*&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> > >::type std::__invoke<void (SfxDispatcher::*&)(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), SfxDispatcher*&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> > >(void (SfxDispatcher::*&)(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), SfxDispatcher*&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&) (invoke.h:95) ==31190== by 0x71475D7: void std::_Bind<void (SfxDispatcher::*(SfxDispatcher*, std::_Placeholder<1>))(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >)>::__call<void, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&, 0ul, 1ul>(std::tuple<std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&>&&, std::_Index_tuple<0ul, 1ul>) (functional:400) ==31190== by 0x713EC45: void std::_Bind<void (SfxDispatcher::*(SfxDispatcher*, std::_Placeholder<1>))(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >)>::operator()<std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >, void>(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&) (functional:484) ==31190== by 0x7138105: std::_Function_handler<void (std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >), std::_Bind<void (SfxDispatcher::*(SfxDispatcher*, std::_Placeholder<1>))(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >)> >::_M_invoke(std::_Any_data const&, std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >&&) (std_function.h:300) ==31190== by 0x74B0DE0: std::function<void (std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >)>::operator()(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >) const (std_function.h:690) ==31190== Address 0x2851fb68 is 40 bytes inside a block of size 136 free'd ==31190== at 0x483A0D6: operator delete(void*, unsigned long) (vg_replace_malloc.c:595) ==31190== by 0x33EB6D8A: SwTextShell::~SwTextShell() (textsh.cxx:838) ==31190== by 0x712DA15: SfxDispatcher::FlushImpl() (dispatch.cxx:1491) ==31190== by 0x7127B39: SfxDispatcher::Flush() (dispatch.cxx:256) ==31190== by 0x33F31D47: SwView::SelectShell() (view.cxx:469) ==31190== by 0x33F323E7: SwView::AttrChangedNotify(LinkParamNone*) (view.cxx:540) ==31190== by 0x33F32166: SwView::LinkStubAttrChangedNotify(void*, LinkParamNone*) (view.cxx:507) ==31190== by 0x32E6E732: Link<LinkParamNone*, void>::Call(LinkParamNone*) const (link.hxx:112) ==31190== by 0x32E64E37: SwCursorShell::CallChgLnk() (crsrsh.cxx:2501) ==31190== by 0x32E4D726: SwCallLink::~SwCallLink() (callnk.cxx:120) ==31190== by 0x32E93C50: SwCursorShell::SelPrevRedline() (crstrvl.cxx:2211) ==31190== by 0x33EAC7D5: SwTextShell::ExecField(SfxRequest&) (textfld.cxx:533)
Created attachment 171690 [details] Screenshot of the Comments dialog in bibisect-7.2 I can no longer reproduce this crash in 7.2 master since: https://cgit.freedesktop.org/libreoffice/core/commit/?id=8e6203bd8f4390698f83a74a04f901437a9a61a3 tdf#126735 sw Next Change: cycle through tracked changes Instead of crashing on opening this dialog (or closing it with OK/Cancel, as I saw it in some other versions during bibisect) now the navigation arrows appear despite there is only a single tracked change in the document.
(In reply to NISZ LibreOffice Team from comment #10) > Created attachment 171690 [details] > Screenshot of the Comments dialog in bibisect-7.2 > > I can no longer reproduce this crash in 7.2 master since: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8e6203bd8f4390698f83a74a04f901437a9a61a3 > > tdf#126735 sw Next Change: cycle through tracked changes > > Instead of crashing on opening this dialog (or closing it with OK/Cancel, as > I saw it in some other versions during bibisect) now the navigation arrows > appear despite there is only a single tracked change in the document. I do confirm the mentioned commit fixes the issue Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 5f51b6f08c6ed6fb135b8d4999d6fb6a51fafa89 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Will create a UITest for this.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/47c0cea5aae8f1ac5c8d79fc09a30c8c5f14af64 tdf#126226: sw: Add UItest It will be available in 7.2.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.
Xisco: many thanks for the test! László
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/58720cad9ad9221d2bc0bb668beff18468d266d5 tdf#126226, tdf#126735 sw Next Change: cycle through tracked changes It will be available in 7.1.4. 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.