Steps to reproduce: 1. Open attachment 99325 [details] from bug 78902 2. Select all 3. Copy 4. Close the document 5. Open it again 6. Select all 7. Copy -> Crash Reproduced in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: c97a3592c78ce276a353f95ce68c70a8a39174a0 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=b802ab694a8a7357d4657f3e11b571144fa7c7bf author Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu> 2021-03-12 14:33:08 +0100 committer László Németh <nemeth@numbertext.org> 2021-03-31 14:44:27 +0200 commit b802ab694a8a7357d4657f3e11b571144fa7c7bf (patch) tree 1c8aba77e9b6aed048d8b49f55ff006c5d099d5f parent 3c49a3be592eb515bba100b4a17617136fabbcba (diff) tdf#141158 DOCX: import discarded headers/footers Bisected with: bibisect-linux64-7.2 Adding Cc: to Attila Bakos
Created attachment 178622 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Created attachment 178625 [details] valgrind trace I also noticed that when reopening the file and did "Select All", there was a kind of picture of the content of the file which partly displays at left, a kind of "ghost" or shadow of the document itself.
After first look i noticed the following: 1) Open the bugdoc 2) Ctrl+A 3) Ctrl+C 4) Close 5) Wait a bit and ->crash The problem likely is a destructing problem, with a leak as in the attachment. Tomorrow i will investigate it more accurately.
Created attachment 178720 [details] Minimised version
Created attachment 178723 [details] The reason of the crash Looks like the problem has been investigated, if i open the https://bugs.documentfoundation.org/attachment.cgi?id=178720&action=edit and do the steps, i have got crash, but if i remove that part of the document of the xml what is marked in this attachment, i will not get crash. That part is this (between a paragraph xml pair): ... <w:sectPr w:rsidR="000D6C44" w:rsidRPr="00C2510B"> <w:headerReference w:type="even" r:id="rId7"/> <w:headerReference w:type="default" r:id="rId8"/> <w:footerReference w:type="default" r:id="rId9"/> <w:headerReference w:type="first" r:id="rId10"/> <w:pgSz w:w="11906" w:h="16838"/> <w:pgMar w:top="680" w:right="680" w:bottom="680" w:left="680" w:header="709" w:footer="709" w:gutter="0"/> <w:cols w:space="708"/> <w:docGrid w:linePitch="360"/> </w:sectPr> ... the only question is: how to obtain such xml from word??? What option i should use to get this? Any idea? Thanks.
And eventually i reached the reproduction steps, here are how to make such document from the beginning: 1) Open new blank docx in Word 2) Insert two section breaks of the type of "next page" 3) Enter to the header and enable the "different odd and even page" option 4) Unlink each header from its beginner one 5) Disable the "different odd and even page" option 6) Save to docx, open in Writer 7) CTRL+A and CTRL+C 8) Close Writer ->Crash will occur As can be seen not so easy to do a document like this. I think the following happen behind of the scene: When the "different odd and even page" option enabled Word creates the header/footer xmls for each section in the docx. When it disabled they are preserved, so writer tries to apply them for each page style, in that case too when it is unnecessary. After copying of the text (with the different headers) and exiting, these headers kept in the memory instead of freeing (leak!) and the OS kills the process. Of course this is a guess, and not sure but it seems like this for me. Fix soon...
Created attachment 180653 [details] The original docx without password Hi there! Forget about my last comments. I have tried to minimize the bugdoc with word, but it complained because that was protected with password. After removing the password from the xml i cannot repro the crash with: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 19632bf0bc0561138f3dee4b2d79a5b3ade0de52 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL I think this issue depends on password protection. How to test it without password? Any idea? Thx.
i found the same UAF yesterday. 1. open https://bugs.documentfoundation.org/attachment.cgi?id=180723 2. select all 3. copy 4. close 5. do something that clears the clipboard, e.g. open new document and copy some text typically it crashes in step 5, but the problem already happens at step 4. the main SwDoc is destroyed, but the clipboard SwDoc has pointers into the main SwDoc's item pool, which is of course not supposed to happen. the problem happens in this code: │ 1545 // Copy the stashed formats as well between the page descriptors... │ 1546 for (bool bFirst : { true, false }) │ 1547 for (bool bLeft : { true, false }) │ 1548 for (bool bHeader : { true, false }) │ 1549 { │ 1550 if (!bLeft && !bFirst) │ 1551 continue; │ 1552 if (auto pStashedFormat = rSrcDesc.GetStashedFrameFormat(bHeader, bLeft, bFirst)) │ > 1553 rDstDesc.StashFrameFormat(*pStashedFormat, bHeader, bLeft, bFirst); │ 1554 } this works if rDstDesc and rSrcDesc are in the same SwDoc, but if different SwDoc all the items inside the SwFrameFormats must be cloned into the destination doc's item pool - but this just calls SwFrameFormat copy ctor so they're in the source SwDoc. see how SwDoc::CopyPageDesc calls special functions CopyHeader/CopyFooter.
Created attachment 181725 [details] ASAN log
note: UAF on close is because SwFormatHeader item owns SfxItemSet (via its GetRegisteredIn() SwFrameFormat) there aren't supposed to be any SwFormatHeader items alive at the time when the SfxItemPool is destroyed - all must be destroyed earlier when all SwPageDescs are destroyed in ~SwDoc. they're not because the other SwDoc increased their refcounts.
Hello Michael, sorry of my late reply. I did not write a lot here since my last comment. Thank you for the advice, yes i also had the same idea according to the backtrace, and i have started to reimplement this in https://gerrit.libreoffice.org/c/core/+/136959 which is currently waits for the finish about a month, because of i do not had time to do that. In addition, there were also problems, but that were a month before so unfortunately i not remember well what was that, maybe crash not remember well, so be careful if you interested in that change, not merge yet, and the local version is different from that in the gerrit (with different problem :)). That had been interrupted, but when i will have time, i want to finish it. However, if i remember well i did not think of that what you wrote, this issue is occurs when there are different swdocs, but as i remember that is true, so thanks for showing me that. Hopefully i can finish it soon.
(In reply to Michael Stahl (allotropia) from comment #9) > i found the same UAF yesterday. > > 1. open https://bugs.documentfoundation.org/attachment.cgi?id=180723 > 2. select all > 3. copy > 4. close > 5. do something that clears the clipboard, e.g. open new document and copy > some text > > typically it crashes in step 5, but the problem already happens at step 4. > > the main SwDoc is destroyed, but the clipboard SwDoc has pointers into the > main SwDoc's item pool, which is of course not supposed to happen. > > the problem happens in this code: > > │ 1545 // Copy the stashed formats as well between the page > descriptors... > │ 1546 for (bool bFirst : { true, false }) > > │ 1547 for (bool bLeft : { true, false }) > │ 1548 for (bool bHeader : { true, false }) > │ 1549 { > │ 1550 if (!bLeft && !bFirst) > │ 1551 continue; > │ 1552 if (auto pStashedFormat = > rSrcDesc.GetStashedFrameFormat(bHeader, bLeft, bFirst)) > │ > 1553 rDstDesc.StashFrameFormat(*pStashedFormat, > bHeader, bLeft, bFirst); > │ 1554 } > > this works if rDstDesc and rSrcDesc are in the same SwDoc, but if different > SwDoc all the items inside the SwFrameFormats must be cloned into the > destination doc's item pool - but this just calls SwFrameFormat copy ctor so > they're in the source SwDoc. > > see how SwDoc::CopyPageDesc calls special functions CopyHeader/CopyFooter. Agree, this is not enough for copying, there must be a deep copy. :)
(In reply to Michael Stahl (allotropia) from comment #11) > note: UAF on close is because SwFormatHeader item owns SfxItemSet (via its > GetRegisteredIn() SwFrameFormat) > > there aren't supposed to be any SwFormatHeader items alive at the time when > the SfxItemPool is destroyed - all must be destroyed earlier when all > SwPageDescs are destroyed in ~SwDoc. > > they're not because the other SwDoc increased their refcounts. Yep, i have seen in the assert the ref count problem, but i did not know the other doc keeps that alive, so thank you for pointing that me. (I had not idea who still owns the item :))
*** Bug 150441 has been marked as a duplicate of this bug. ***
Still crashing with comment 0 or comment 9 steps in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b83f069101f1e6d8aaac09a805f02bbc4c619e7a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Attila, are you still working on it or should it be unassigned?
the problem was fixed by quikee. the commit introduced a memory leak though, which i have a fix for in gerrit. commit 963de9feb37105560fde14b44d992e47f341bb5b Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> AuthorDate: Thu Nov 30 16:42:26 2023 +0900 Commit: Tomaž Vajngerl <quikee@gmail.com> CommitDate: Fri Dec 1 05:07:42 2023 +0100 sw: fix issue with copying stashed frame format When the PageDesc is copied from one document to another, we don't make sure the stashed FrameFormat(s) are also properly copied to the new document (which can happen at copy/paste). This can cause a crash if the stashed FrameFormats are accessed or destructed after the original document is destroyed. This fixes the issue so that when we detect the PageDesc belong to different documents, the stashed FrameFormats are copied just like the non-stashed FrameFormats (used for headers and footers). Change-Id: I948068dba4d39bb47c3725dfa8491c53c5833c7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160065 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5c4ae1b19c51dcd62dad8e1d3e8beb87a0311352 tdf#147731 sw: fix memory leak in SwDoc::CopyPageDesc() 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.
No crash with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2fa44db6f8a1badece63856ee0f12db4cba9b28 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thank you!
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a06a5905df7af2f6b69133e419dbfa99d232ab02 tdf#147731 sw: fix memory leak in SwDoc::CopyPageDesc() It will be available in 24.2.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/737f8ce51d47e030b4cd6d955ef24cfb71c185c2 tdf#147731 sw: fix memory leak in SwDoc::CopyPageDesc() It will be available in 7.6.6. 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.