Created attachment 192562 [details] GDB trace of crash Use a debug build and save and reload a blank document in Impress or Draw and you will see a crash. #0 0x00007a87925cbc4b in SfxItemPool::IsInRange (this=0x9999999999999999, nWhich=5508) at include/svl/itempool.hxx:308
Reproduced in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d677ed49bb975dbf3f810d27a5c6477e6df07cf2 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
On pc Debian x86-64 with master sources updated today, I could reproduce this. I don't reproduce this with LO Debian package 24.0.2.3 => regression Armin: one for you?
*** Bug 159763 has been marked as a duplicate of this bug. ***
Bibisect shows this started in: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ae7807c889c19145f89cec40afac82eee191837c commit ae7807c889c19145f89cec40afac82eee191837c (HEAD, refs/bisect/bad) Author: Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Date: Wed Jan 10 20:07:47 2024 +0100 ITEM: No longer register Items at Pool Indeed it happens only in dbgutil build, when the saved Impress file is reloaded.
Tried with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded on fresh master, gcc build on linux using --enable-dbgutil I tried: - start LO - new Impress - save - use menu 'reload' -start LO - new Impress - save - close - load ...and also with restart LO and load -> could not reproduce, sorry.
Looking at the attached stack: LineNumbers do not fit to master. getTargetPool calls getTargetPool -> 1st IsInRange was false. Uses mpSecondary for next call to getTargetPool, that gets us to a wrong this ptr -> mpSecondary is not initialized (?) mpSecondary is a rtl::Reference<SfxItemPool> mpSecondary; and gets initialized in both constructors using , mpSecondary() (not really needed, but is even done) so should contain nullptr. Another possibility may be SfxRequest_Impl::~SfxRequest_Impl: it destroys a set SfxPoolItemHolder aRetVal using the remembered pool. If that pool is already deleted that may happen (but would have led to problems before?). There is also SfxRequest_Impl::SetPool that may change the pool member. In that case aRetVal *should* be reset which is not done yet. OTOH that was std::unique_ptr<SfxPoolItem> pRetVal; // Return value belongs to itself before, so ~SfxPoolItem would have been called in the same situation, but would indeed *survive* without/changed/deleted pool. Hmmm... Need to reproduce - any tipps..?
(In reply to Armin Le Grand from comment #6) > > Need to reproduce - any tipps..? You can try Regina's description (see https://bugs.documentfoundation.org/show_bug.cgi?id=159763#c0)
Thanks for the tipp, but also could not reproduce -> no hint until now... Have tried multiple times again, with empty & reaload, current master, Regina's BugDoc, ... no crash here
Anyone? I can still not reproduce, guessing around... Maybe someone has another stack? Is someone willing who can reproduce to check if I offer a patch...?
(In reply to Armin Le Grand from comment #9) > Anyone? I can still not reproduce, guessing around... > Maybe someone has another stack? > Is someone willing who can reproduce to check if I offer a patch...? Sure, I can build your patch and check.
@ilmari.lauhakangas@libreoffice.org: could you please try https://gerrit.libreoffice.org/c/core/+/165883
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b4626d809b50f1d5c1aa8a9644dd3913f5b15503 tdf#159719 reset SfxPoolItemHolder when Pool changes It will be available in 24.8.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.
@ilmari.lauhakangas@libreoffice.org: Thanks for checking!