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. ***