How to reproduce: 1. Create a new document with Writer 2. Ctrl + K to pen the Hyperlink dialog 3. Go to the Document tab on the left 4. Click the button to the right of the Target box, under the "Target in Document" section Happens in Writer. Works in "Version: 6.0.5.1", so a regression. Found in master: Version: 6.2.0.0.alpha0+ Build ID: 7c666e66b7f176bd8910e64f6008ff24151b37a5 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2018-06-06_02:03:28 Locale: en-US (en_US.UTF-8); Calc: group threaded
Created attachment 142573 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today + enable-dbgutil, I got an assert.
Noel: I noticed it crashes because of line 686: 686 { OUString(UNO_LINK_DISPLAY_BITMAP), 0, cppu::UnoType<css::awt::XBitmap>::get(), PropertyAttribute::READONLY, 0xff}, 687 { OUString(UNO_LINK_DISPLAY_NAME), 0, cppu::UnoType<OUString>::get(), PropertyAttribute::READONLY, 0xbf}, Just wonder what's the meaning of 0xff and 0xbf, I noticed that a lot of 0xff had been changed to 0xbf with https://cgit.freedesktop.org/libreoffice/core/commit/?id=ae5f89fdcccb2cf74256b04771249fc8afca879
This patch fixes the assert and I don't have a crash: diff --git a/sw/source/core/unocore/unomap.cxx b/sw/source/core/unocore/unomap.cxx index 8445e08f935d..3dffbe6859fc 100644 --- a/sw/source/core/unocore/unomap.cxx +++ b/sw/source/core/unocore/unomap.cxx @@ -683,7 +683,7 @@ const SfxItemPropertyMapEntry* SwUnoPropertyMapProvider::GetPropertyMapEntries(s { static SfxItemPropertyMapEntry const aLinkTargetMap_Impl[] = { - { OUString(UNO_LINK_DISPLAY_BITMAP), 0, cppu::UnoType<css::awt::XBitmap>::get(), PropertyAttribute::READONLY, 0xff}, + { OUString(UNO_LINK_DISPLAY_BITMAP), 0, cppu::UnoType<css::awt::XBitmap>::get(), PropertyAttribute::READONLY, 0xbf}, { OUString(UNO_LINK_DISPLAY_NAME), 0, cppu::UnoType<OUString>::get(), PropertyAttribute::READONLY, 0xbf}, { OUString(), 0, css::uno::Type(), 0, 0 } }; Now, since I don't know the meaning of 0xbf/0xff, I hesitate to submit this on gerrit.
that fix is correct, in the past the code was setting 0x40 in that field to indicate that the field is METRIC i.e. needs conversion. I fixed that in ae5f89fdcccb2cf74256b04771249fc8afca8794, but obviously missed that one. Want to push a fix?
(In reply to Noel Grandin from comment #4) > ... > Want to push a fix? No pb but I'll be able to do it only when get back to home. If someone wants to do it before, fine for me too.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fccc7aebb5285e36530b14001e37b33b586365f9 tdf#118042: fix crash on Target box in Hyperlink dialog 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.
For 6.1: https://gerrit.libreoffice.org/#/c/55443/ is on review.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=243b73546c0c0b291f5e05405ad24e48df625d64&h=libreoffice-6-1 tdf#118042: fix crash on Target box in Hyperlink dialog It will be available in 6.1.0.1. 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 in Version: 6.2.0.0.alpha0+ Build ID: 4c6e11886a9d396bf7be18e9e3209a73c6e303ad CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Julien, Thanks for fixing this!!