Description: Entering multiple Hyperlinks in Writer followed by Undo on one of the Hyperlinks results in crash on Libreoffice 24.8.1.1 Steps to Reproduce: 1.Open Libreoffice Writer. 2. Type a Hyperlink (eg. amazon.com or e-mail address, e.g. mymail@yahoo.com ) followed by a space (this turns the plain text (e.g. amazon.com or mymail.com) into a Hyperlink. 3. Type another Hyperlink, followed by a space (by pressing the Space bar on your keyboard). 4. Next, hold down the Ctrl key on your keyboard and press the Z key (like Zebra) on your keyboard. Actual Results: When the Ctrl-Z combination in Step 4 is carried out, Libreoffice 24.8.1.1 crashes. Expected Results: When the Ctrl-Z combination in Step 4 is carried out, the Hyperlink function should simply be undone (i.e. dark blue coloring, underline and Hyperlink function). Reproducible: Always User Profile Reset: No Additional Info: Libreoffice Version 24.8.1.1 (X86_64) OS: Ubuntu 12.04 LTS (Linux kernel 5.4) CPU Threads: 4 Motherboard: ASRock J3455-ITX CPU Type: "Intel(R) Celeron(R) CPU J3455 @ 1.50GHz" This bug persists when Libreoffice is started in safe mode.
Reproducible Version: 24.8.1.1 (X86_64) / LibreOffice Community Build ID: ef51c4a0cd35185debf25ad9d0db6a1c14bed5a0 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded But no reproducible with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c8eb95e8407ef24436e0e8e218dce535df6bb2e5 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Latest version that works on the ones I have installed. Version: 24.2.6.2 (X86_64) / LibreOffice Community Build ID: ef66aa7e36a1bb8e65bfbc63aba53045a14d0871 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded
Regression introduced by: commit ca3c6d468f68af1506bf4e56b47655e5d56306a8 [log] author Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Fri Feb 09 11:13:58 2024 +0100 committer Armin Le Grand <Armin.Le.Grand@me.com> Mon Feb 12 10:35:33 2024 +0100 tree 27da565a170606c4ea54ea07aa0dbb21eba3fe60 parent 207501b8385818a5d413b9f4001e0d24aaa4f2a9 [diff] ITEM: ItemPool Rework (I) Bisected with: bibisect-linux64-24.8
This is by far the most reported issue in LibreOffice 24.8. Increasing importance
The commit added this comment: https://opengrok.libreoffice.org/xref/core/sw/source/core/bastyp/init.cxx?r=56d35ad0#339 seems to be related
Created attachment 196378 [details] ASAN report
(In reply to Xisco Faulí from comment #4) > The commit added this comment: > https://opengrok.libreoffice.org/xref/core/sw/source/core/bastyp/init. > cxx?r=56d35ad0#339 seems to be related That is for the global default Item. It's just that it does not get statically initialized in ItemInfoArrayWriter maItemInfos, but at 1st call to getItemInfoPackageSwAttributes(), thus in ItemInfoPackageSwAttributes::ItemInfoPackageSwAttributes() what is fine. This ensures that that Item cannot be accessed without being incarnated. I think it has more to do with the wild stuff of SwCharFormat and derived classes. That was one of that classes that 'parked' Items directly in the Pool (without ItemSet) and I changed that to SfxPoolItemHolder in SwTextAttr. In my current master this does not happen using the Description, so I might have to build a version to get that stack. What exactly do I need to checkout to get that? Is Reproducible Version: 24.8.1.1 (X86_64) / LibreOffice Community Build ID: ef51c4a0cd35185debf25ad9d0db6a1c14bed5a0 directly the git version I need...?
(In reply to Armin Le Grand from comment #6) > In my current master this does not happen using the Description, so I might > have to build a version to get that stack. What exactly do I need to > checkout to get that? Is Can you share the info from Help - About LibreOffice? I can reproduce it with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3e8183e0c4b4c116cbd9187bfdfa7dfdf447805e CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded and Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b418f3d8d332276e6990cf7532a8f66aeb1d2f6c CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Steps: 1. Open writer 2. type 'test@libreoffice.org' 3. type space 4. type 'test@libreoffice.org' 5. type space 6. Undo once or twice -> Crash
With the above steps, I can reproduce now with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3e8183e0c4b4c116cbd9187bfdfa7dfdf447805e CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
(In reply to Xisco Faulí from comment #7) > Can you share the info from Help - About LibreOffice? Sure: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c37d18c0a8dbe77ead043a1f3dce86192ca74a79 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded > Steps: > 1. Open writer > 2. type 'test@libreoffice.org' > 3. type space > 4. type 'test@libreoffice.org' > 5. type space > 6. Undo once or twice > > -> Crash Seems just not to happen everytime, but I was lucky (?) now, got the crash. LO output: soffice.bin: /home/alg/lo/h_work01/include/svl/itemset.hxx:70: const SfxPoolItem* SfxPoolItemHolder::getItem() const: Assertion `!isDeleted() && "Destructed instance used (!)"' failed. Indeed the SfxPoolItemHolder (which has a dbg-only member bDeleted) states to be deleted. Stack: libc.so.6!__assert_fail(const char * assertion, const char * file, unsigned int line, const char * function) (assert.c:103) libswlo.so!SfxPoolItemHolder::getItem(const class SfxPoolItemHolder * const this) (/home/alg/lo/h_work01/include/svl/itemset.hxx:70) libswlo.so!SwTextAttr::GetINetFormat(const class SwTextAttr * const this) (/home/alg/lo/h_work01/sw/inc/txatbase.hxx:253) libswlo.so!SwTextINetFormat::GetCharFormat(class SwTextINetFormat * const this) (/home/alg/lo/h_work01/sw/source/core/txtnode/txtatr2.cxx:140) libswlo.so!SwTextINetFormat::GetCharFormat(const class SwTextINetFormat * const this) (/home/alg/lo/h_work01/sw/inc/txtinet.hxx:54) libswlo.so!CharFormat::GetItemSet(const class SfxPoolItem & rAttr) (/home/alg/lo/h_work01/sw/source/core/text/atrstck.cxx:146) libswlo.so!CharFormat::GetItem(const class SwTextAttr & rAttr, sal_uInt16 nWhich) (/home/alg/lo/h_work01/sw/source/core/text/atrstck.cxx:164) libswlo.so!CharFormat::GetItem<SvxCharHiddenItem>(const class SwTextAttr & rAttr, class TypedWhichId<SvxCharHiddenItem> nWhich) (/home/alg/lo/h_work01/sw/inc/charfmt.hxx:54) Have to continue tomorrow, but interestingly *this from SwTextAttr::GetINetFormat is 0x55555acc6010 while in SwTextINetFormat::GetCharFormat it is 0x55555acc5fd0 (?). Also wondering why in SwTextINetFormat::GetCharFormat() the line const SwFormatINetFormat& rFormat = SwTextAttrEnd::GetINetFormat(); is used, not just const SwFormatINetFormat& rFormat = GetINetFormat(); Is there some strange class hierarchy...?
Getting closer. Indeed happens in the UNDO, the SwTextINetFormat that later causes the crash by being accessed is deleted there. Stack is: libsvllo.so!SfxPoolItemHolder::~SfxPoolItemHolder(SfxPoolItemHolder * const this) (/home/alg/lo/h_work01/svl/source/items/itemset.cxx:171) libswlo.so!SwTextAttr::~SwTextAttr(SwTextAttr * const this) (/home/alg/lo/h_work01/sw/source/core/txtnode/txatbase.cxx:46) libswlo.so!SwTextINetFormat::~SwTextINetFormat(SwTextINetFormat * const this) (/home/alg/lo/h_work01/sw/source/core/txtnode/txtatr2.cxx:136) libswlo.so!SwTextINetFormat::~SwTextINetFormat(SwTextINetFormat * const this) (/home/alg/lo/h_work01/sw/source/core/txtnode/txtatr2.cxx:136) libswlo.so!SwTextAttr::Destroy(SwTextAttr * pToDestroy) (/home/alg/lo/h_work01/sw/source/core/txtnode/txatbase.cxx:61) libswlo.so!SwTextNode::DeleteAttributes(SwTextNode * const this, const sal_uInt16 nWhich, const sal_Int32 nStart, const sal_Int32 nEnd) (/home/alg/lo/h_work01/sw/source/core/txtnode/thints.cxx:1878) libswlo.so!SwHistoryResetText::SetInDoc(SwHistoryResetText * const this, SwDoc * pDoc) (/home/alg/lo/h_work01/sw/source/core/undo/rolbck.cxx:444) libswlo.so!SwHistory::TmpRollback(SwHistory * const this, SwDoc * pDoc, sal_uInt16 nStart, bool bToFirst) (/home/alg/lo/h_work01/sw/source/core/undo/rolbck.cxx:1237) Thus a good place for a BP is sw/source/core/txtnode/thints.cxx:1878 where pTextHt gets destroyed (A). BUT that instance is later accessed by the stack in comment 9 since it still gets referenced by a SwFormatINetFormat and accessed using rAttr.StaticWhichCast(RES_TXTATR_INETFMT).GetTextINetFormat()->GetCharFormat() in sw/source/core/text/atrstck.cxx:146 (B). Thus (A) deletes something that is still referenced by (B). I guess (A) would also have to cleanup the reference to (A) in (B). I have no idea about that SW code there. Why did that work before? Probably because that Items put directly in the Pool were never deleted due to their RefCnt not really working - these were deleted by a kind of 'silent garbage collection' when the pool got deleted itself (at SW shutdown). That RefCnt stuff was never cleaned-up, maybe by purpose (?).
Short Note: If I comment out sw/source/core/txtnode/thints.cxx:1878 (in SwTextNode::DeleteAttributes) the crash is gone, but I have no idea if this is a possible fix (?)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f6dc87fc730bc48a7c809d2ff460cc36024630b9 tdf#162911 sw: fix crash after autocorrect inserts hyperlinks It will be available in 25.2.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.
should be fixed now
Michael, thanks for your help here!
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/524461f8080793ac7d7dc282c0dd52551e556d30 tdf#162911 sw: add an assert not to use default items It will be available in 25.2.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8896b00efb8a8c455caef04c1bb1d3ec94348b80 tdf#162911: autocorrect: Add unittest It will be available in 25.2.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/cf7e2d3742c82598fc2974bd43861281c3ca5496 tdf#162911 sw: fix crash after autocorrect inserts hyperlinks It will be available in 24.8.2. 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.
*** Bug 162994 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/7f1af7501242c799afd35aeed2ab798b431fbdbe tdf#162911: autocorrect: Add unittest It will be available in 24.8.2. 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.
*** Bug 163011 has been marked as a duplicate of this bug. ***
*** Bug 163025 has been marked as a duplicate of this bug. ***