Created attachment 84408 [details] Screenshot of garbled styles and formatting dialog While working with an .odt document the styles and formatting dialog may appear garbled (see attached screenshot) pronouncing an entire application crash shortly after closing the dialog. The crash might occur a few seconds later without user interaction, on some other operation but certainly when closing the application window. The issue does not occur - with 4.0.4 on OSX - with 4.1.4 on linux using the very same document. Also looking at https://bugs.freedesktop.org/show_bug.cgi?id=67326 https://bugs.freedesktop.org/show_bug.cgi?id=67688 it looks like something is seriously wrong with the OSX build of 4.1.4
Created attachment 84409 [details] Crashlogs
Comment on attachment 84408 [details] Screenshot of garbled styles and formatting dialog Mimetype fixed
masc: - did you install any LO specific extensions? - could you try to rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile) and test again?
> - did you install any LO specific extensions? no. > - could you try to rename your LO directory profile (see > https://wiki.documentfoundation.org/UserProfile) and test again? deleted all LO user profiles, issue persists.
masc: thank you for your feedback. Caolán: user's bts show this: 0 libvcllo.dylib 0x01a29eec Window::GetParent() const + 12 1 libvcllo.dylib 0x01a309bc Window::ImplIsRealParentPath(Window const*) const + 44 2 libvcllo.dylib 0x01a30a1c Window::ImplSetFrameParent(Window const*) + 60 3 libvcllo.dylib 0x01a403ff Window::SetParent(Window*) + 95 4 libvcllo.dylib 0x01a056c7 SplitWindow::RemoveItem(unsigned short, unsigned char) + 167 5 libsfxlo.dylib 0x00624a17 SfxSplitWindow::RemoveWindow(SfxDockingWindow*, unsigned char) + 247 6 libsfxlo.dylib 0x005ec4f0 SfxDockingWindow::ReleaseChildWindow_Impl() + 544 7 libsfxlo.dylib 0x005ec67b SfxDockingWindow::~SfxDockingWindow() + 43 8 libsfxlo.dylib 0x00638e3d SfxTemplateDialog::~SfxTemplateDialog() + 61 9 libsfxlo.dylib 0x0052bf8a SfxChildWindow::~SfxChildWindow() + 58 10 libsfxlo.dylib 0x00642ac8 SfxTemplateDialogWrapper::~SfxTemplateDialogWrapper() + 40 11 libsfxlo.dylib 0x0052c4a8 SfxChildWindow::Destroy() + 328 12 libsfxlo.dylib 0x00577393 SfxWorkWindow::DeleteControllers_Impl() + 211 A search on ImplIsRealParentPath gives this: 1476 sal_Bool Window::ImplIsRealParentPath( const Window* pWindow ) const 1477 { 1478 pWindow = pWindow->GetParent(); 1479 while ( pWindow ) 1480 { 1481 if ( pWindow == this ) 1482 return sal_True; 1483 pWindow = pWindow->GetParent(); 1484 } 1485 1486 return sal_False; 1487 } (see http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#1476) Shouldn't pWindow be tested before calling GetParent() on it line 1478? (BTW, I don't know why pWindow would be NULL here)
visually its the dropcaps page which is superimposed on the indents and spacing dialog, which of course is "impossible"
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecf12c8286fece4e6f86dccbb37bff6794f0867e Related: fdo#68396 FrameSelectorImpl draws before being initialized 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.
I can't reproduce this problem, but I did find a use of an initialized value with valgrind. If anyone can reproduce this problem, it would be great if they could check tomorrows daily with the above fix to see if it has any bearing on this problem
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d422eeed14f34e8595f795135be847fe5b6c5556&h=libreoffice-4-1 Related: fdo#68396 FrameSelectorImpl draws before being initialized It will be available in LibreOffice 4.1.2. 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.
*** Bug 68379 has been marked as a duplicate of this bug. ***
Given the response in bug 68379 I'll going to call this fixed
Created attachment 84826 [details] CrashLog master~2013-08-29_07.14.27_LibreOfficeDev_4.2.0.0.alpha0_MacOS_x86-64
Issue persists with master~2013-08-29_07.14.27_LibreOfficeDev_4.2.0.0.alpha0_MacOS_x86-64. To me #68379 does not really look related (at all).
Comment on attachment 84826 [details] CrashLog master~2013-08-29_07.14.27_LibreOfficeDev_4.2.0.0.alpha0_MacOS_x86-64 Mimetype fixed
So, where do you click that makes it crash seeing as it appears to be clicking on some element which tries to create a PopupMenu
I managed to replicate it using a fresh document. Here's a screencast. https://docs.google.com/file/d/0B75pW_mdMdLXRVVYenRtWUpac1U/edit?usp=sharing The garbled styles dialog does not occur with 4.2.0.0, but the crash does. After recording the screencast I found that - it's not necessary to enter any text - it's not necessary to change style to "default style" - it doesn't matter which style is edited - it doesn't matter if the OK or Cancel button is used for closing the style dialog What is crucial for the crash to happen is: - Nested tables - The style dialog has to be opened using the "styles and formatting" window. When using "Edit paragraph style" using the context menu (which opens the same dialog) the crash will not occur. - The context menu has to be opened and closed after the style dialog was closed. The crash will not occur unless the context menu has been closed. There might be other paths to replicate it, but this is what I found for now.
Please be aware that this issue seems OSX only. While I can reproduce it every time on OSX, I could never replicate it on Linux.
Finally figured this one out. There are multiple pages getting generated in the styles dialog because the dropcaps preview window calls "Yield" sometimes and sometimes the layout timer gets a chance to activate *during* the creation of the dialog so there ends up with two consecutive activations of some tabpages which has wonderful eventual know on effects resulting in that crash later on. Easiest thing is to disable the layout timer during the initial size calculation
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe1cbda3b7513e0d3686d347aa991e7231067384 Resolves: fdo#68396 Yield allowed layout timer to run during init layout 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.
fixed in master, proposed for 4-1 as https://gerrit.libreoffice.org/5696
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e71befa4756de72675569649684fb4c34773e9b&h=libreoffice-4-1 Resolves: fdo#68396 Yield allowed layout timer to run during init layout It will be available in LibreOffice 4.1.2. 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.
great, works fine now with master~2013-09-04_01.37.11_LibreOfficeDev_4.2.0.0.alpha0_MacOS_x86-64.dmg