Description: If I open Impress build with debug symbols and I'm trying to open character properties dialog, an assertion is occurred and application closes. Steps to Reproduce: 1. Open Impress with debug symbols 2. Open character properties dialog: Format -> Character... Actual Results: Assertion dialog comes up. Expected Results: Should not be assertion here. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Confirmed with 5.3 master build / Windows 7. Seems to be OS-independent, so adjusting OS to All, change back if it can't be reproduced with a debug build in Linux. The assert is this one, and for some reason pops up twice: assert(!"unknown which - don't ask me for defaults"); http://opengrok.libreoffice.org/xref/core/svl/source/items/itempool.cxx#812 Version: 5.3.0.0.alpha1+ Build ID: afe235a0abf9ef91a353a4d0dccf56961abd2fbf CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; Locale: hu-HU (hu_HU); Calc: CL
On pc Debian x86-64 with master sources updated today + enable-dbgutil, I don't reproduce the assert (gtk3 + gen rendering) Any update with more recent sources? If assert reproduced, any chance for a bt?
(In reply to Julien Nabet from comment #2) > On pc Debian x86-64 with master sources updated today + enable-dbgutil, I > don't reproduce the assert (gtk3 + gen rendering) > > Any update with more recent sources? > If assert reproduced, any chance for a bt? No repro with Impress. However, I can produce this with Draw: 1. Open Draw with debug symbols 2. Open character properties dialog: Format -> Character... Version: 6.0.0.0.alpha0+ Build ID: 9ca7bda2cc8b67c2d10fcb81cce8bfd4d8b79b09 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-08-02_01:19:29 Locale: nl-NL (nl_NL); Calc: CL
Created attachment 135189 [details] Call stack I can still repro like before. This is the closest to a backtrace I can get in VS. The following piece might be interesting: In SvxFontPrevWindow::SetFromItemSet(...) it goes through a couple of items: Preview string, Underline etc., and fails in Background. https://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#1047
fixed on master, probably by: commit 6284804c2ccb3ad8bb6e1c1dac8d622f66b8c07d Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Fri Aug 11 12:26:30 2017 +0100 move the SvxBackgroundColorItem<->SvxBrushItem conversion into the dialog itself