I get a crash if I do: 1. Start LibreOffice Calc or Writer. 2. Click the "New" toolbar button to create a new file. 3. Close the new window ("Untitled 2") by clicking the cross icon in the caption bar. 4. From the File menu select "Open...". Also tested Impress, problem does not occur. Using LO 5.0.2.2 on Microsoft Windows 7 Professional (version 6.1, build 7601: SP1)
I only see the cross icon, when I have one document open. Trick for weird things like this: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
I tested on another computer, same Windows version. I deleted %APPDATA%\Roaming\LibreOffice to create a new profile. The crash still occurred following the steps listed. If you don't see a cross icon, pressing Alt+F4 or double-clicking the icon in the top left also reproduces the problem in my tests.
I am unable to make it crash.
I asked a colleague to try this and he could reproduce the issue by following the steps. He's using Microsoft Windows 10.
Sorry, I was able to make it crash in 5.0.2 after all :) Not crashing in 5.1, though.. Maybe it was already noticed and fixed? I could not find a duplicate report. Let's try to remember to test with 5.0.3 RC1 when it is released: https://wiki.documentfoundation.org/ReleasePlan/5.0#5.0.3_release Not crashing in 4.3, marking as regression. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI) Version: 5.1.0.0.alpha1+ Build ID: 25de5cfa43b2b1cb7d7214470acc7719839e13fe TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-01_08:49:54 Locale: en-US (fi_FI)
Created attachment 119342 [details] Backtrace of crash on Windows 5.0.2
Trace is: > sclo.dll!ScViewData::GetDispatcher() Line 2105 C++ 'this' is NULL here. sclo.dll!ScDocShell::Execute(SfxRequest & rReq) Line 1102 C++ case SID_OPEN_CALC: { SfxStringItem aApp(SID_DOC_SERVICE, OUString("com.sun.star.sheet.SpreadsheetDocument")); SfxStringItem aTarget(SID_TARGETNAME, OUString("_blank")); GetViewData()->GetDispatcher().Execute( SID_OPENDOC, SfxCallMode::API|SfxCallMode::SYNCHRON, &aApp, &aTarget, 0L); } So presumably GetViewData is NULL ... - hmm... sclo.dll!SfxStubScDocShellExecute(SfxShell * pShell, SfxRequest & rReq) Line 1060 C++ sfxlo.dll!SfxShell::CallExec(void (SfxShell *, SfxRequest &) * pFunc, SfxRequest & rReq) Line 210 C++ sfxlo.dll!SfxDispatcher::Call_Impl(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, bool bRecord) Line 261 C++ sfxlo.dll!SfxDispatcher::_Execute(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, SfxCallMode eCallMode) Line 849 C++ sfxlo.dll!SfxBindings::Execute_Impl(SfxRequest & aReq, const SfxSlot * pSlot, SfxShell * pShell) Line 1282 C++ sfxlo.dll!SfxDispatchController_Impl::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & rListener) Line 845 C++ sfxlo.dll!SfxOfficeDispatch::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs) Line 359 C++ fwklo.dll!framework::MenuBarManager::Select(Menu * pMenu) Line 1037 C++ fwklo.dll!framework::MenuBarManager::LinkStubSelect(void * instance, void * data) Line 973 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!Menu::Select() Line 303 C++ vcllo.dll!Menu::ImplCallSelect(void * __formal) Line 2205 C++ vcllo.dll!Menu::LinkStubImplCallSelect(void * instance, void * data) Line 2201 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent) Line 2041 C++ vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalFrame * __formal, unsigned short nEvent, const void * pEvent) Line 2593 C++ vcllo.dll!SalFrame::CallCallback(unsigned short nEvent, const void * pEvent) Line 247 C++
Interesting; the explanation is quite 'simple' ;-) there is an ordering change caused by the Idle re-work; and two idle handlers race each other: an asynchronous focus handling [ huh ] ... races with the 2nd trace: sfxlo.dll!SfxFrameWindow_Impl::GetFocus() Line 174 C++ vcllo.dll!vcl::Window::CompatGetFocus() Line 3975 C++ vcllo.dll!vcl::Window::ImplGrabFocus(unsigned short nFlags) Line 388 C++ vcllo.dll!vcl::Window::GrabFocus() Line 3153 C++ tklo.dll!VCLXWindow::setFocus() Line 1024 C++ fwklo.dll!`anonymous namespace'::Frame::focusGained(const com::sun::star::awt::FocusEvent & aEvent) Line 2346 C++ tklo.dll!FocusListenerMultiplexer::focusGained(const com::sun::star::awt::FocusEvent & evt) Line 76 C++ tklo.dll!VCLXWindow::ProcessWindowEvent(const VclWindowEvent & rVclWindowEvent) Line 587 C++ tklo.dll!VCLXWindow::WindowEventListener(VclSimpleEvent * pEvent) Line 419 C++ tklo.dll!VCLXWindow::LinkStubWindowEventListener(void * instance, void * data) Line 408 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!VclEventListeners::Call(VclSimpleEvent * pEvent) Line 64 C++ vcllo.dll!vcl::Window::CallEventListeners(unsigned long nEvent, void * pData) Line 217 C++ vcllo.dll!vcl::Window::PreNotify(NotifyEvent & rNEvt) Line 71 C++ vcllo.dll!SystemWindow::PreNotify(NotifyEvent & rNEvt) Line 185 C++ vcllo.dll!vcl::Window::CompatPreNotify(NotifyEvent & rNEvt) Line 3998 C++ vcllo.dll!ImplCallPreNotify(NotifyEvent & rEvt) Line 61 C++ vcllo.dll!vcl::Window::ImplGrabFocus(unsigned short nFlags) Line 386 C++ vcllo.dll!vcl::Window::GrabFocus() Line 3153 C++ vcllo.dll!vcl::Window::ImplAsyncFocusHdl(void * __formal) Line 1806 C++ vcllo.dll!vcl::Window::LinkStubImplAsyncFocusHdl(void * instance, void * data) Line 1782 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent) Line 2041 C++ vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalFrame * __formal, unsigned short nEvent, const void * pEvent) Line 2593 C++ vcllo.dll!SalFrame::CallCallback(unsigned short nEvent, const void * pEvent) Line 247 C++ vcllo.dll!ImplHandleUserEvent(HWND__ * hWnd, long lParam) Line 4130 C++ vcllo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef) Line 5786 C++ vcllo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 5945 C++ user32.dll!_InternalCallWinProc@20() Unknown user32.dll!_UserCallWinProcCheckWow@32() Unknown user32.dll!_CallWindowProcAorW@24() Unknown user32.dll!_CallWindowProcW@20() Unknown opengl32.dll!_wglWndProc@16() Unknown user32.dll!_InternalCallWinProc@20() Unknown user32.dll!_UserCallWinProcCheckWow@32() Unknown user32.dll!_DispatchMessageWorker@8() Unknown user32.dll!_DispatchMessageW@4() Unknown vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg) Line 600 C++ vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 616 C++ vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents, unsigned long nReleased) Line 676 C++ vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents, const unsigned long nReleased) Line 358 C++ vcllo.dll!Application::Yield() Line 386 C++ vcllo.dll!Application::Execute() Line 336 C++ sofficeapp.dll!desktop::Desktop::Main() Line 1607 C++ vcllo.dll!ImplSVMain() Line 169 C++ vcllo.dll!SVMain() Line 207 C++ sofficeapp.dll!soffice_main() Line 96 C++ soffice.bin!sal_main() Line 48 C soffice.bin!main(int argc, char * * argv) Line 47 C soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47 C soffice.bin!__tmainCRTStartup() Line 618 C soffice.bin!WinMainCRTStartup() Line 466 C kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!___RtlUserThreadStart@8() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown After this - an async (?) Close_Foo ... > sfxlo.dll!SfxApplication::SetViewFrame_Impl(SfxViewFrame * pFrame) Line 321 C++ sfxlo.dll!SfxViewFrame::SetViewFrame(SfxViewFrame * pFrame) Line 3302 C++ sfxlo.dll!SfxViewFrame::Close() Line 1122 C++ sfxlo.dll!SfxFrame::DoClose_Impl() Line 170 C++ sfxlo.dll!SfxBaseController::dispose() Line 1030 C++ fwklo.dll!`anonymous namespace'::Frame::setComponent(const com::sun::star::uno::Reference<com::sun::star::awt::XWindow> & xComponentWindow, const com::sun::star::uno::Reference<com::sun::star::frame::XController> & xController) Line 1550 C++ fwklo.dll!`anonymous namespace'::Frame::close(unsigned char bDeliverOwnership) Line 1781 C++ fwklo.dll!framework::pattern::frame::closeIt(const com::sun::star::uno::Reference<com::sun::star::uno::XInterface> & xResource, bool bDelegateOwnership) Line 80 C++ fwklo.dll!framework::CloseDispatcher::implts_closeFrame() Line 492 C++ fwklo.dll!framework::CloseDispatcher::impl_asyncCallback(void * __formal) Line 360 C++ fwklo.dll!framework::CloseDispatcher::LinkStubimpl_asyncCallback(void * instance, void * data) Line 244 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!vcl::EventPoster::DoEvent_Impl(vcl::UserEvent * pEvent) Line 54 C++ vcllo.dll!vcl::EventPoster::LinkStubDoEvent_Impl(void * instance, void * data) Line 49 C++ vcllo.dll!Link<void *,long>::Call(void * data) Line 127 C++ vcllo.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent) Line 2041 C++ vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalFrame * __formal, unsigned short nEvent, const void * pEvent) Line 2593 C++ vcllo.dll!SalFrame::CallCallback(unsigned short nEvent, const void * pEvent) Line 247 C++ vcllo.dll!ImplHandleUserEvent(HWND__ * hWnd, long lParam) Line 4130 C++ vcllo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef) Line 5786 C++ vcllo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 5945 C++ user32.dll!_InternalCallWinProc@20() Unknown user32.dll!_UserCallWinProcCheckWow@32() Unknown user32.dll!_CallWindowProcAorW@24() Unknown user32.dll!_CallWindowProcW@20() Unknown opengl32.dll!_wglWndProc@16() Unknown user32.dll!_InternalCallWinProc@20() Unknown user32.dll!_UserCallWinProcCheckWow@32() Unknown user32.dll!_DispatchMessageWorker@8() Unknown user32.dll!_DispatchMessageW@4() Unknown vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg) Line 600 C++ vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 616 C++ vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents, unsigned long nReleased) Line 676 C++ vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents, const unsigned long nReleased) Line 358 C++ vcllo.dll!Application::Yield() Line 386 C++ vcllo.dll!Application::Execute() Line 336 C++ sofficeapp.dll!desktop::Desktop::Main() Line 1607 C++ vcllo.dll!ImplSVMain() Line 169 C++ vcllo.dll!SVMain() Line 207 C++ sofficeapp.dll!soffice_main() Line 96 C++ soffice.bin!sal_main() Line 48 C soffice.bin!main(int argc, char * * argv) Line 47 C soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47 C soffice.bin!__tmainCRTStartup() Line 618 C soffice.bin!WinMainCRTStartup() Line 466 C kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!___RtlUserThreadStart@8() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown Sets that baby to zero (from another idle handler ...) This breaks the assumption that we will always get a focus -after- the close is done ... What an ugly heap ! =) we need to get the ordering right (or better) to aggressively de-lame-ify the Window/VCL <-> Sfx interaction.
Interestingly, after poking at the main-loop for a while I discovered that these are both posted events; so either we're posting them in the wrong order, or emitting them in the wrong order; either being interesting =)
Urgh - this bug is a horror - it would be fantastic to have a bibisect of it, we're loosing focus events (somehow) - but quite how is really unclear. Thanks !
This is Windows-only. Not reproduced on Linux. Ubuntu 15.10 64-bit Version: 5.0.2.2 Build ID: 00m0(Build:2) Locale: en-US (en_US.UTF-8)
Created attachment 120643 [details] bibisect log
Laszlo - thanks for the bibisect =) am I reading the trace right - does it get us down to just this one commit: git log b9f95769495e8d9885b64f1d68118336a4fc8d38..7aae8772aa18744cb1bbd8348272be99cc882c47 commit 7aae8772aa18744cb1bbd8348272be99cc882c47 Author: Michael Meeks <michael.meeks@collabora.com> Date: Fri Jun 5 16:37:49 2015 +0100 Clear VclPtr instance reference on removed UserEvents.
> Laszlo - thanks for the bibisect =) am I reading the trace right - does it > get us down to just this one commit: Thanks, Michael. I tried to bibisect the commit, that fixed this problem in 5.1, and I have got the following one: commit 187445b2d2885ced92be37ffb11cd2a9bb11f8d6 Author: Laurent Godard <lgodard.libre@laposte.net> Date: Mon Jun 8 10:24:42 2015 +0200 Uno api sidebar unit test tdf#91806 - python test subsequentcheck - correct deck setTitle APi (UI update) - enhance UnoInProcess for flexiility in loading parameter I found the relevant line in it, checked successfully in lo-5-0, and pushed commit to the gerrit: https://gerrit.libreoffice.org/#/c/20250/
Nice work - thanks Laszlo ! =) pushed to 5-0
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d101b6296962b444f535eeb2ff37580dc9bb60c&h=libreoffice-5-0 tdf#94689 fix crash on new file, close file, open file It will be available in 5.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
LibreOffice crashed for me on Windows, but I was not able to recreate the steps to reproduce it; hence I could not write a bug. Thank you for fixing this bug.
Fixing is verified in a fresh libreoffice-5-0 build. Michael: thanks for the review and pushing. Óvári: thanks for your comment, I hope, this fix will solve your problem with the next bug fix release of LibreOffice 5.0.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]