Created attachment 120911 [details] document LibreOffice crashes immediatelly on opening attached document.
Created attachment 120917 [details] Backtrace of crash on Windows, LibO 5.0.3 Reproduced. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI)
Also crashes in 4.3 after scrolling and clicking once. No crash in 3.5.
Actually, looks like one of backports to 4.1.6.
Created attachment 120966 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce the crash.
Created attachment 120968 [details] simple patch The attached patch fixes several bts (included the first one I encountered). However, I've got a hanging (perhaps a loop in layout management)
Michael: I attached a simple (perhaps naive patch) for several bts I encountered. But then I'm stuck with a hanging in layout management part. Anyway, perhaps you might be interested in this one.
Given that this is a regression and a crasher I'm going to push it to highest. I believe everything that needs to be done has been done from QA. 56a3b3c781fc2eb55f46641d89a866a91119a8a3 is the first bad commit commit 56a3b3c781fc2eb55f46641d89a866a91119a8a3 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun May 11 21:09:15 2014 +0000 source-hash-21e6fd2b2dfdb806db320f699e434e6f2351a7b6 commit 21e6fd2b2dfdb806db320f699e434e6f2351a7b6 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Thu Mar 6 11:42:47 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Mar 6 16:35:44 2014 +0000 coverity#1190350 Dereference after null check Change-Id: Ia863c587b998270f68e6a6439891ce18a07ed626 :100644 100644 92c5df078bd2356a2b4b3f3bab5dab0d2a074f96 d55443e790ba39a1df1b828e1f87313792dacd4d M autogen.log :100644 100644 764536980b5c9ec649f2a5b5ddacb9be6b112d38 2f86eb48b7ad1da4a303e31eaf18bac562594b81 M ccache.log :100644 100644 8a44e3d39a7e24f6baaa2898abc76c07e3670d50 6fbfbc3578eb16d5baafa016c39bb60eac97f3cb M commitmsg :100644 100644 33fb3d77fcf181542ea93798adebf649b97a11c6 803e23cb80ad94afe1e67611a0b727e9c1a74a0d M make.log :040000 040000 080158650746b3d1b5cf843aa396652d230a78b6 3a8036dc8e1b2345e98f501c4b0be373d63681bd M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb # good: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b git bisect good e1d0365cd2b073a859f59ad0a4584385a66dc611 # skip: [8f55938c891ee3e4c252b193dba9419f130537bc] source-hash-93f3f72d18e551c8edd6a010cb78d9cbe404f8ef git bisect skip 8f55938c891ee3e4c252b193dba9419f130537bc # good: [7518fcaf863962bf4f6f3cdf84f6e42f0f59225f] source-hash-ab1f5eab4830f00dbbd7c883b98b59975ecd3bb1 git bisect good 7518fcaf863962bf4f6f3cdf84f6e42f0f59225f # bad: [56a3b3c781fc2eb55f46641d89a866a91119a8a3] source-hash-21e6fd2b2dfdb806db320f699e434e6f2351a7b6 git bisect bad 56a3b3c781fc2eb55f46641d89a866a91119a8a3 # good: [1b1974dec96ab21a79c3f574f3654a9515fed9d0] source-hash-51f74e362b364e51f13f3abaa00df1aa01c81cef git bisect good 1b1974dec96ab21a79c3f574f3654a9515fed9d0 # good: [2f040759edbb7bb8e7a41cf06bac2a2a0fb50c73] source-hash-76fe205d7e0fe0a73616453209d8094cab9ce79f git bisect good 2f040759edbb7bb8e7a41cf06bac2a2a0fb50c73 # first bad commit: [56a3b3c781fc2eb55f46641d89a866a91119a8a3] source-hash-21e6fd2b2dfdb806db320f699e434e6f2351a7b6
Both of the backtrace show a null pointer deref at: #1 0x00002aaad6fbc4ce in SwSection::GetFormat() (this=0x0) at sw/inc/section.hxx:343 #2 0x00002aaad74db3cb in SwSectionFrame::_Grow(long, bool) (this=0x9a37ce0, nDist=37890, bTst=false) at sw/source/core/layout/sectfrm.cxx:1883 git log 76fe205d7e0fe0a73616453209d8094cab9ce79f..21e6fd2b2dfdb806db320f699e434e6f2351a7b6 sw/source/ shows no obvious candidate for the regression, but: - Miklos Vajna fixing DOC filters and DOCX export - mst adding some asserts - Zolnai Tamás work on alignment/layout - Caolán McNamara doing some coverity Nothing jumps at me as the obvious candidate for the regression, but the alignment/layout work is IMHO closest/most risky. Would need a bisect in the bibisected area.
2b78f2cd7b9e4bab0f3b3b9119238f36a1bbc7b2 is the first bad commit commit 2b78f2cd7b9e4bab0f3b3b9119238f36a1bbc7b2 Author: Michael Stahl <mstahl@redhat.com> Date: Wed Mar 5 23:29:06 2014 +0100 rhbz#988516: DOCX import: fix context stack when importing header/footer When a header/footer substream is parsed, a ParagraphGroup is started, but not ended; so the properties of the last paragraph in the header/footer are applied to a paragraph in the body. The obvious fix to add a call to endParagraphGroup() at the end of w:p element breaks table cells. So add a call to endParagraphGroup() at the end of the "hdr"/"ftr" element. (The problem in the bugdoc became much more visible with commit ca555c596043c88894b964ac5e21f5a7271d5f3b, but was there before)
using "soffice --convert-to odt" we find that the resulting ODT file also causes a layout crash when scrolling, since the commit from comment #9. the ODT file triggers the layout crash since OOo 3.4 beta, whereas OOo 3.3 and older versions refuse to import the file at all. the main difference between a ODT file with and without the commit from comment #9 is that we get extra paragraph numbering since the paragraph that starts with "Verze": now all following paragraphs are numbered. so there are actually 2 bugs here, the regression that paragraphs are wrongly in a list, and the pre-existing layout crash. i'll make this bug about the crash, and open a new bug for the list regression. the new bug is 97417.
Created attachment 122258 [details] first attachment converted to ODT ODT document that also triggers the crash
I can open and scroll DOCX now but ODT crashes. "Verze" page looks OK with 2 columns although LO has no Section break (Continuous). Just to note: MSO opens 8 pages and LO opens 10 pages in DOCX due to Section break (Continuous) issue behind "Radek Kotas, 737270381" and table split before "Kontaktní osoba zákazníka". It changed throughout versions. Version: 5.2.0.0.alpha0+ Build ID: 91c072b473beadda01a38dbc26086207c7b4d145 CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-02_06:12:40
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=727ebae15e623660b9cc6f8db0e7558830bf920d Resolves: tdf#96172 crashtesting: avoid crash in layout It will be available in 5.2.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.
On Gerrit review: for 5.1, https://gerrit.libreoffice.org/24154 for 5.0, https://gerrit.libreoffice.org/24155
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a91536cdaae48cfd1eb82fe2ffd1cf2bed3dcb7&h=libreoffice-5-1 Resolves: tdf#96172 crashtesting: avoid crash in layout It will be available in 5.1.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-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=43685487f24bc2a1244922ebc04af467f0eabef6&h=libreoffice-5-0 Resolves: tdf#96172 crashtesting: avoid crash in layout It will be available in 5.0.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. But why target:5.0.7 and not 5.0.6.2?
> Thank you. But why target:5.0.7 and not 5.0.6.2? See https://wiki.documentfoundation.org/Development/Branches#libreoffice-X-Y-Z
Well, I'm aware of X-Y-Z and it's not about Z, but the question is: why 5.0.7 when https://wiki.documentfoundation.org/ReleasePlan doesn't mention 5.0.7 at all? And why not 5.0.6.2 when RC2 is still not over? Is it explained somewhere?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f3e79a0493bf297fe165e974f4f9f044f5c7ed3&h=libreoffice-5-0-6 Resolves: tdf#96172 crashtesting: avoid crash in layout It will be available in 5.0.6. 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.