First action after updating to 7.0 using Writer; recovery dialog also hangs (worked after app was killed). After restart it shows the menu until the Edit section. Classic variants work. Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Mac OS X 10.15.5; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
Happens also with master.
Not reproducible in Version: 7.1.0.0.alpha0+ Build ID: 76c40b82e6a44539cd43f326c00246e759449571 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded with a clean profile.
(In reply to Xisco Faulí from comment #2) > Not reproducible in > with a clean profile. Yes, no crash in safe mode.
Not reproduced Version: 7.1.0.0.alpha0+ Build ID: 35021cd56b3b4e38035804087f215c80085564be CPU threads: 8; OS: Mac OS X 10.14.6; UI render: default; VCL: osx Locale: en-US (en_ES.UTF-8); UI: en-US Calc: threaded Removing /Users/libreoffice/Library/Application\ Support/LibreOfficeDev/4/user/ first. Please, provide the steps to reproduce it. is experimental feature enabled ?
(In reply to Xisco Faulí from comment #4) > Removing /Users/libreoffice/Library/Application\ > Support/LibreOfficeDev/4/user/ first. See comment 3, experimental features off.
So, is it a corrupted profile issue ?
(In reply to Xisco Faulí from comment #6) > So, is it a corrupted profile issue ? Seems so
I can't reproduce this Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: en-ID (en_ID.UTF-8); UI: en-US Calc: threaded
Crash happens in weld.hxx at SpinButton(): int normalize(int nValue) const { return (nValue * Power10(get_digits())); } with EXC_BAD_ACCESS (code=EXC_I386_GPFLT). No crash running in safe mode (aka clean user profile). Any idea, Caolan?
I don't know if it's the same problem reported here, but here is one way to make it crash: 1. Open 6.4 version of Writer. 2. Tools > Customize... 3. Don't make any changes, just close the dialog and LO. 4. Open 7.0 version of Writer using the same user profile as 6.4. 5. View > User Interface > Tabbed => Crash The problem here is that just opening the customization dialog copies the notebookbar.ui file to the user profile, and the file from 6.4 isn't compatible with 7.0. This is related to the OptionalBox changes discussed in Bug 130513, which at first was moved from sfx2 to vcl w/o adapting the ui files, and then in Bug 130513 its factory function was removed, which broke loading of existing notebookbar.ui files from the user profile. I guess we can workaround it for now by explicitly handling sfxlo-OptionalBox widget kind, but we really should discard existing notebookbar.ui files when an upgrade to a major release is detected. Or even better - not use the glade ui format for storing user customization, as it might change over time. In addition, I think that the customization dialog should not copy anything to the user profile, unless actual changes were made.
Hi Maxim, https://crashreport.libreoffice.org/stats/signature/VCLXAccessibleComponent::GetWindow might also be related to the same problem, where the notebookbar is involved in the traces
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2d0944ab7a94ea0d5cd5f66c4895a0c99d9a3593 author Caolán McNamara <caolanm@redhat.com> 2020-02-08 19:18:15 +0000 committer Caolán McNamara <caolanm@redhat.com> 2020-02-08 21:46:32 +0100 commit 2d0944ab7a94ea0d5cd5f66c4895a0c99d9a3593 (patch) tree bd3423599f7dd325a5ac690dfb6a29c46ff408b3 parent e4033c9a27e68f7e7ec6f6949509a1bffaeb4508 (diff) Resolves: tdf#130513 sfxlo-OptionalBox isn't in sfx Bisected with: bibisect-linux64-7.0 Adding Cc: to Caolán McNamara I followed the steps from comment 10 in order to bisect it
I'm sure before notebook customization went in I flagged not to store old .ui snippets in config and was reassured a number of times that wasn't what would happen ?
*** Bug 135512 has been marked as a duplicate of this bug. ***
https://www.spinics.net/lists/libreoffice/msg02253.html *annoyed mumble*
*** Bug 135542 has been marked as a duplicate of this bug. ***
I'll bodge it to work like it used to with https://gerrit.libreoffice.org/c/core/+/100361 Looking at the customization for the future, as far as I can see so far all that we actually customize in a notebook is the visibility of an entry ?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f9eea764389eae7e6b77076c1a80a8e6f280f9c4 tdf#135495 builder file format has annoyingly escaped into user config It will be available in 7.1.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.
backport to 7-0 as https://gerrit.libreoffice.org/c/core/+/100361 A pity there's a dependency on the .ui file format, we'll have to try and fix that up. But for the immediate problem right now this seems sufficient.
Verified in ( copying user profile from 6.4 ) Version: 7.1.0.0.alpha0+ Build ID: 0de191e1d201d691c2196cf1aef412a98affb66f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Caolán, thanks for fixing this issue!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/f14a738fa8c5579c2ef8cb8387b771e94ea5bdfe tdf#135495 builder file format has annoyingly escaped into user config It will be available in 7.0.1. 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.
*** Bug 134910 has been marked as a duplicate of this bug. ***