Description: On pc Debian x86-64 with master sources updated today + enable-dbgutil + gtk3, I don't have SpreadSheet, Draw, etc in Autocaption Steps to Reproduce: 1. Open Writer 2. Tools/Options 3. Select LibreOffice Writer 4. Select AutoCaption Actual Results: Here's the list: LibreOffice Writer Table LibreOffice Writer Frame LibreOffice Writer Image Other OLE Objects Other OLE Objects Other OLE Objects Other OLE Objects Other OLE Objects Expected Results: Here's the list: LibreOffice Writer Table LibreOffice Writer Frame LibreOffice Writer Image LibreOffice Spreadsheet LibreOffice Drawing LibreOffice Formula LibreOffice Chart LibreOffice Presentation Reproducible: Always User Profile Reset: Yes Additional Info: In sw/source/ui/config/optload.cxx, in SwCaptionOptPage::Reset, I noticed that behaviour is ok if I first create a variable corresponding to SvGlobalName(SO3_OUT_CLASSID) then compare rOleId with it User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
I don't reproduce this with LO Debian package 5.2.5.1 => Regression
Created attachment 132119 [details] screenshot I can't reproduce it in ( see screenshot ) Version: 5.4.0.0.alpha0+ Build ID: 1670cc25bc2771e87f7956a4b0dd634abaa4128b CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Can not reproduce on today's TB42 build for Windows x86 on Windows 10 Pro 64-bit en-US, the full list of OLE types with just one "Other OLE Objects" check box selection is generated. Version: 5.4.0.0.alpha0+ Build ID: 522e9c65faef684a22151ddf009a5a192838b522 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-03-24_00:32:45 Locale: en-US (en_US); Calc: CL
On MacOs with master sources updated some days ago, I don't reproduce this. Terrence: would you have a little time to give it a try? Indeed, this one seems hard to reproduce. For example, perhaps it needs enable-dbgutil
Thank you for thinking of me, Julien. Working on debian-stretch, I do not see the bug in daily Linux dbgutil bibisect repository versions 2017-02-02, 2017-02-03, 2017-03-22. This is true with the my user profile as I found it, in safe mode, and naming a new profile directory on the command line. However, I *do* see the bug in my local build of commit 9ba5eb22, pulled 2017-02-02, configured CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --without-package-format I have compared the generated user profiles, dbgutil bibisect repo vs. localbuild. The differences are benign except possibly pack/autotext/mytexts.pack and pack/registrymodifications.pack, which are binary files that I do not know how to read. Setting SAL_USE_VCLPLUGIN={gen,gtk3} did not make any difference. I am setting status NEW.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a7d008a8dfdc0a8b42061329b5e756b1b034abaf Resolves: tdf#106732 the intent was surely to return a const ref It will be available in 5.4.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.
I think this will work now
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d9736ca79ed3205bb091787e09ebb736ffd808a3&h=libreoffice-5-3 Resolves: tdf#106732 the intent was surely to return a const ref It will be available in 5.3.3. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1946bdabb8132a1989024f1bcd1d24806e1fae9e&h=libreoffice-5-2 Resolves: tdf#106732 the intent was surely to return a const ref It will be available in 5.2.7. 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.
Thank you Caolán! I won't be able to check the fix for the moment to put the tracker to VERIFIED since I'm away for a week but I'll do it when I come back.
My local build of commit 7e03a22b, pulled 2017-04-08, in the same environment I described in comment 5, shows the desired results. Caolán, if you know why my earlier local build showed the problem when the daily dbgutil builds did not, that would increase the importance of my current observation.
caolanm->Terrence: Do you still see this bug after my most recent change above ? Its appearance/disappearance in earlier versions may be somewhat random, i.e. use after free, in some cases the freed memory may be unchanged so it works anyway, while in other cases its reused so there's a bit of randomnesss to it
Terrence->caolanm No, no crash now. I was just warning against paying too much attention to one no-crash result. Thank you for the fix and your answer.
I could check it's ok this morning, after having updated my local repo. Thank you Caolán!