Bug 145567

Summary: Crash when click "File > Open" if previously a Draw document is opened via Writer and closed
Product: LibreOffice Reporter: Kevin Suo <suokunlong>
Component: DrawAssignee: Caolán McNamara <caolan.mcnamara>
Status: VERIFIED FIXED    
Severity: normal CC: caolan.mcnamara
Priority: medium Keywords: bibisected, haveBacktrace, regression
Version: 7.1.0.0.alpha0+   
Hardware: All   
OS: Linux (All)   
Whiteboard: target:7.3.0 target:7.2.5
Crash report or crash signature: Regression By:
Attachments: gdb full backtrace

Description Kevin Suo 2021-11-06 07:29:47 UTC 
Created attachment 176132 [details]
gdb full backtrace

Steps to Reproduce:
1. New Writer;
2. File > Open, select a Draw document (either an odg or PDF file), OK. The document is now opened in Draw which is expected. 
3. Close the Draw window. The Writer windows remains open (this is also expected). Now in the Writer window, click File > Open.

--> Crash.

Terminal output which may be related:

warn:sd:174782:174782:sd/source/ui/unoidl/DrawController.cxx:806: Calling disposed DrawController object. Throwing exception:
warn:svl.items:174782:174782:svl/source/items/itempool.cxx:358: old secondary pool: EditEngineItemPool of pool: XOutdevItemPool must be empty


Gdb backtrace shows the following:

#0  0x00007ffff47472e5 in std::__uniq_ptr_impl<SfxDispatcher_Impl, std::default_delete<SfxDispatcher_Impl> >::_M_ptr() const (this=0x0) at /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/unique_ptr.h:173
#1  0x00007ffff47472a5 in std::unique_ptr<SfxDispatcher_Impl, std::default_delete<SfxDispatcher_Impl> >::get() const (this=0x0) at /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/unique_ptr.h:422
#2  0x00007ffff473a615 in std::unique_ptr<SfxDispatcher_Impl, std::default_delete<SfxDispatcher_Impl> >::operator->() const (this=0x0) at /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/unique_ptr.h:416
#3  0x00007ffff4722735 in SfxDispatcher::IsLocked() const (this=0x0) at sfx2/source/control/dispatch.cxx:197
#4  0x00007ffff47283c9 in SfxDispatcher::ExecuteList(unsigned short, SfxCallMode, std::initializer_list<SfxPoolItem const*>, std::initializer_list<SfxPoolItem const*>)
    (this=0x0, nSlot=5501, eCall=(SfxCallMode::SYNCHRON | SfxCallMode::API), args=..., internalargs=...) at sfx2/source/control/dispatch.cxx:932
#5  0x00007fffbba0d585 in SwDocShell::Execute(SfxRequest&) (this=0x258e5b0, rReq=...) at sw/source/uibase/app/docsh2.cxx:1188
#6  0x00007fffbb9f5755 in SfxStubSwDocShellExecute(SfxShell*, SfxRequest&) (pShell=0x258e5b0, rReq=...) at workdir/SdiTarget/sw/sdi/swslots.hxx:1409
#7  0x00007ffff4722c91 in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) (this=0x2713b40, rShell=..., rSlot=..., rReq=..., bRecord=true) at sfx2/source/control/dispatch.cxx:253
#8  0x00007ffff4723502 in SfxDispatcher::PostMsgHandler(std::unique_ptr<SfxRequest, std::default_delete<SfxRequest> >) (this=0x2713b40, pReq=std::unique_ptr<SfxRequest> = {...}) at sfx2/source/control/dispatch.cxx:989

Full backtrace attached.

Version: 7.3.0.0.alpha1+ / LibreOffice Community
Build ID: 8fbd4a5f6850ed94169f50617dc97c5fb054504b
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN
Calc: threaded
Fedora 34 x64.
Comment 1 Kevin Suo 2021-11-06 07:51:24 UTC 
I also note that there is no crash if you following the steps if there is no user profile generated (i.e., no reproduce if you are running the application for the first time). After a first run of the application user profile is generated, and now if you follow the steps there is crash.
Comment 2 Kevin Suo 2021-11-06 08:17:29 UTC 
This is a regression.

Bibisected to the following range: f4a5893eceabc1f6d541164a0e858456f0ce0905..2d1a8f83ce4c74b2ede1e93e8e1d309a61b8af23

2d1a8f83ce4c (fix welded editengine delete-surrounding, 2020-10-22)
f09cd9d20a01 (tdf#137520 shrink some text glyphs in icons, 2020-10-16)
5a342bde16fb (weld backing window, 2020-10-15)

Adding Caolán McNamara to cc list. Could you please take a look? Thanks.
Comment 3 Caolán McNamara 2021-11-06 20:50:04 UTC 
This is focus related, the crash happens because the dispatcher is null, and the dispatcher is set when the frame get focus and the focus didn't get set on the frame
Comment 4 Commit Notification 2021-11-07 14:35:11 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6645dfedef841a78d65202e9f0008f0a384e5e44

Resolves: tdf#145567 restore focus to the usual frame focus widget

It will be available in 7.3.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.
Comment 5 Caolán McNamara 2021-11-07 14:37:22 UTC 
fone in trunk, backport to 7-2 in gerrit
Comment 6 Kevin Suo 2021-11-07 15:33:45 UTC 
Thank you Caolan for the quick fix!
Verified fixed on master.
Comment 7 Commit Notification 2021-11-15 11:32:28 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/ac3c1de61e7cf069d3022907570832130235fa32

Resolves: tdf#145567 restore focus to the usual frame focus widget

It will be available in 7.2.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.
Comment 8 Christian Lohmaier 2021-12-06 13:28:48 UTC 
7.2.4 was a hotfix release, updating target in status-whiteboard