On Windows 10 Home 64-bit en-US with Version: 6.2.0.0.alpha0+ (x64) Build ID: bf1f49c837264c8f59197b9487d40e32821526c3 CPU threads: 4; OS: Windows 10.0; UI render: GL (or default) TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-16_23:03:41 Locale: en-US (en_US); Calc: CL On launching the Character dialog from menu or context menu. Any module. Crash with and without OpenGL rendering enabled. Looks to be in SfxTabDialog =-stack-= 0:000> ~* kp . 0 Id: 2804.12fc Suspend: 1 Teb: 0000003e`194e0000 Unfrozen # Child-SP RetAddr Call Site 00 0000003e`19f8e298 00007ffc`5e403514 vcllo!Button::SetClickHdl+0x3 01 0000003e`19f8e2a0 00007ffc`5e3fd2e5 cuilo!makeBackgroundPreview+0x13ec4 02 0000003e`19f8e2f0 00007ffc`5e3fb141 cuilo!makeBackgroundPreview+0xdc95 03 0000003e`19f8e3e0 00007ffc`5e4000ae cuilo!makeBackgroundPreview+0xbaf1 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\LODev620_x64_20180617_TB42\program\sfxlo.dll - 04 0000003e`19f8e420 00007ffc`6877294a cuilo!makeBackgroundPreview+0x10a5e 05 0000003e`19f8e460 00007ffc`68777481 sfxlo!SfxTabDialog::ActivatePageHdl+0x1ea 06 0000003e`19f8e580 00007ffc`68777278 sfxlo!SfxTabDialog::Start_Impl+0x1a1 07 0000003e`19f8e600 00007ffc`643527cd sfxlo!SfxTabDialog::StartExecuteAsync+0x48 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\LODev620_x64_20180617_TB42\program\swlo.dll - 08 0000003e`19f8e630 00007ffc`5f089410 vcllo!VclAbstractDialog::StartExecuteAsync+0xfd 09 0000003e`19f8e730 00007ffc`5f085110 swlo!SwTextShell::GetState+0x32d0 0a 0000003e`19f8e9a0 00007ffc`686a263f swlo!SwTextShell::Execute+0x2000 0b 0000003e`19f8f450 00007ffc`686a63ce sfxlo!SfxDispatcher::Call_Impl+0x25f 0c 0000003e`19f8f510 00007ffc`6889f431 sfxlo!SfxDispatcher::PostMsgHandler+0xbe 0d 0000003e`19f8f570 00007ffc`63f43eb7 sfxlo!com_sun_star_comp_sfx2_GlobalEventBroadcaster_get_implementation+0x1c1 0e 0000003e`19f8f5a0 00007ffc`6433984f vcllo!FloatingWindow::ImplSetMouseDown+0x517 0f 0000003e`19f8f6e0 00007ffc`6433c9ac vcllo!CommandMediaData::GetPassThroughToOS+0x41ff 10 0000003e`19f8f720 00007ffc`6433cefd vcllo!WorkWindow::IsFullScreenMode+0x9ec 11 0000003e`19f8f7a0 00007ffc`9a60b85d vcllo!WorkWindow::IsFullScreenMode+0xf3d 12 0000003e`19f8f810 00007ffc`9a60b1ef USER32!UserCallWinProcCheckWow+0x2ad 13 0000003e`19f8f980 00007ffc`64304322 USER32!DispatchMessageWorker+0x19f 14 0000003e`19f8fa00 00007ffc`64303e5b vcllo!WinBlocklistParser::parse+0xa4c2 15 0000003e`19f8fa90 00007ffc`64215b01 vcllo!WinBlocklistParser::parse+0x9ffb 16 0000003e`19f8fad0 00007ffc`6ca1e2d4 vcllo!Application::Execute+0x161 17 0000003e`19f8fb30 00007ffc`6421e89e sofficeapp+0xe2d4 18 0000003e`19f8fd50 00007ffc`6421ed82 vcllo!DeInitVCL+0xbce 19 0000003e`19f8fd90 00007ffc`6ca540c5 vcllo!SVMain+0x32 1a 0000003e`19f8fdc0 00007ff6`77f2102e sofficeapp!soffice_main+0x75 1b 0000003e`19f8fe80 00007ff6`77f21317 soffice+0x102e 1c 0000003e`19f8feb0 00007ffc`9a561fe4 soffice!main+0x2d7 1d 0000003e`19f8fef0 00007ffc`9cabcb31 KERNEL32!BaseThreadInitThunk+0x14 1e 0000003e`19f8ff20 00000000`00000000 ntdll!RtlUserThreadStart+0x21
Created attachment 142822 [details] WinDbg stack trace at 2nd chance with LO's symbols
Tomaž, think this may be your new FontFeatureDialog...
I can reproduce it in Version: 6.2.0.0.alpha0+ Build ID: 6fcc60b49215acb28edac46bb605767840abd122 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-17_00:25:35 Locale: es-ES (es_ES); Calc: group threaded
Not noted on the 20180616 TB42 build -- so, https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=2c85607101e2e04e870e3b87362f39f9a9148e6c..bf1f49c837264c8f59197b9487d40e32821526c3
Bibisected to the following commit using bibisect-win32-6.2: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3aa8a048776bdf0d4868847baac2a72aa55cd6a3 author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-06-15 20:08:18 +0200 committer Tomaž Vajngerl <quikee@gmail.com> 2018-06-16 20:17:15 +0200 "tdf#58941 Manipulate with font features using FontFeatureDialog" Strangely I couldn't reproduce it with the bibisect repo initially, only with daily build 2018-06-18_03:17:36. When I copied over the 'share' directory from the daily build to the bibisect repo's, I got the crash, but only on one of my Win 7 systems, not on the other. I could also repro it with repo lo-linux-dbgutil-daily, see bug 118228 comment 4.
*** Bug 118211 has been marked as a duplicate of this bug. ***
*** Bug 118208 has been marked as a duplicate of this bug. ***
*** Bug 118228 has been marked as a duplicate of this bug. ***
Does it crash only when you have Asian / CTL disabled?
(In reply to Tomaz Vajngerl from comment #9) > Does it crash only when you have Asian / CTL disabled? Indeed, that seems to be the case.
Now I know which bug number to put in the fix :)
Yup, enabling either CJK or CTL, or both (Tools -> Options -> Language Settings -> Languages: Default Languages for Documents checkboxes) eliminates all crashes. Setting back to Western only recreates the crashes.
*** Bug 118243 has been marked as a duplicate of this bug. ***
Created attachment 142938 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Patch submitted on gerrit here: https://gerrit.libreoffice.org/#/c/56124/
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=19b098f123f4566a870081e14c837d57f643489d tdf#118212: fix crash with character format It will be available in 6.2.0. 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.
Verified and its working with Version: 6.2.0.0.alpha0+ Build ID: 8cc60b05c688e0edc03a63da0afd85f1e853bbc3 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threaded
What is the protocol here? If "commit notification" asks for affected users to confirm but it has already been marked as "verified, fixed", do we still need to do that?
=> Resolved Fixed when the commit correcting the issue is known--often by the dev doing the correction or competent QA team member then, => Verified Fixed when competent QA or OP confirms the correction. This issue (all flavors) is VERIFIED FIXED by commit ref in comment 16, needs no further action this issue of crashing on Character format dialog launch.
*** Bug 118301 has been marked as a duplicate of this bug. ***