Problem description: Steps to reproduce: 1. download http://www.3gpp.org/ftp/specs/archive/25_series/25.331/25331-b40.zip 2. extract the archive contents 3. open 25331-b40.doc Current behavior: LibreOffice uses 100%, the GUI appears frozen. Expected behavior: The document is opened without issues. Operating System: Debian Version: unspecified
Created attachment 87799 [details] console bt on master On pc Debian x86-64 with master sources updated today, I didn't reproduce the problem but had a crash. Since I built with debug mode, perhaps the pbs are linked.
Michael: infinite loop or crash, it seems there's a pb here, one for you?
Thank you for your bug report, I can reproduce this bug running Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a OS: Mac osx 10.9.
Created attachment 88075 [details] Crash log Mac osx 10.9
I've got 8GB of memory. Hangs for me on Win 7 64-bit 4.3.2.2. Doesn't hang on dev build Version: 4.4.0.0.alpha0+ Build ID: 276a046d5256b14478ab283f420654df6ae76b55 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-08_00:21:52 Please test with 4.4.0.0 alpha on other OSs.
On pc Debian x86-64 with master sources updated today, it hangs (at least 20 secs, I didn't wait more) at half of the progress bar.
Created attachment 107631 [details] random bt part Here's a random bt part with master sources updated on pc Debian x86-64
Opens after waiting a bit on Windows 4.5. On Ubuntu and 4.5, the progress bar went on for about 40 minutes, finishing, it seems, but then LibO froze in the "grey state". What's the most exciting, though, is that using 3.5 on Linux it doesn't freeze! Adding request for bibisect. Win 7 64-bit Version: 4.5.0.0.alpha0+ Build ID: 8c7f6830e767897d3a0e88f75fc8d7ef7fca95dc TinderBox: Win-x86@42, Branch:master, Time: 2015-01-06_00:47:25 Ubuntu 14.10 64-bit Version: 4.5.0.0.alpha0+ Build ID: f92183833fa569006602ac7e93c906d2094e0d4d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-12-14_00:21:45 LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
I did it! git bisect start # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect bad 423a84c4f7068853974887d98442bc2a2d0cc91b # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e # good: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect good 8a39227e344637eb7154a10ac825d211e64d584c # bad: [e4c742a9e244bd7ebeabc50c90182df28ac3daaf] source-hash-c52ba433491afbca70aa1977a624c795bdd5b9ef git bisect bad e4c742a9e244bd7ebeabc50c90182df28ac3daaf # bad: [96a055e15ee7171a28888973a3c3a7307dd9867f] source-hash-9ca02a663c3eee2698eb360dd5dc7afb1951e743 git bisect bad 96a055e15ee7171a28888973a3c3a7307dd9867f # bad: [74328ea761f699662228f05e71c6214af2abf719] source-hash-35be7d7574cd0f45a18ee5838dd14cb1040890d4 git bisect bad 74328ea761f699662228f05e71c6214af2abf719 # bad: [3e74c2f3e7426e024d76ddb46945fdda53eb695e] source-hash-3a35fd8f1c6b176e675b998a82526636aad5a00b git bisect bad 3e74c2f3e7426e024d76ddb46945fdda53eb695e # bad: [b2c3b987024faeeabd2e45187cb08b5eee4c4629] source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac git bisect bad b2c3b987024faeeabd2e45187cb08b5eee4c4629 # first bad commit: [b2c3b987024faeeabd2e45187cb08b5eee4c4629] source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac b2c3b987024faeeabd2e45187cb08b5eee4c4629 is the first bad commit commit b2c3b987024faeeabd2e45187cb08b5eee4c4629 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Dec 9 10:01:11 2012 +0000 source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac commit a90d7788a4b9aca4378cd1660293403db3d399ac Author: Matúš Kukan <matus.kukan@gmail.com> AuthorDate: Sat May 5 14:47:15 2012 +0200 Commit: Matúš Kukan <matus.kukan@gmail.com> CommitDate: Sat May 5 16:23:10 2012 +0200 fix typo Change-Id: Ie8987092a63e9a3b5d3b94f7ae54fbef98fdfc2c :100644 100644 2a41905990ab8d65e03878c3cd6450dc2b328165 709fc38885d14fa36c79d0ffd56697732aaeb1e9 M autogen.log :100644 100644 eabeaf3d34d05774c496b5584282c48ae8c0da01 f9e38ceeb82e907f35251af8eb5048a3b0badf69 M ccache.log :100644 100644 1a0108dc6a39a69f9834cfbd10b7d6e1adc59333 af80ad8491640fbf2e789dc9c18ca2f95e7a53ae M commitmsg :100644 100644 e1412f59d4a8d4269f0dd5cbb0d32406f596bb0e 5480044878c3a4ef7822e2c23b52e485df07f8d0 M dev-install.log :100644 100644 7501639183011cc5664425c97de14d06a231e47a ef1e0e5a2ab7a64919c1b733828d6b413e1124fe M make.log :040000 040000 b78cd837c04c22973606d712c84aa41280bb03d4 6015723cc86af1fe3db81770464664915b88868b M opt
R.Yu: thank you for the bibisect Here's the shortcut: cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf..a90d7788a4b9aca4378cd1660293403db3d399ac
I dont know what I can do next with bibisected info. How to compile LO and so on.
(In reply to R.Yu. from comment #11) > I dont know what I can do next with bibisected info. How to compile LO and > so on. About the bibisected info, it'll help devs. About building LO, here's the main page to give a start: https://wiki.documentfoundation.org/Development
This is already fixed in 4.4.0.2; The file opens for me in 50 seconds, which is as fast as it has ever opened historically (considering it is a 2199 page file, this isn't doing too badly) 4.3.5.2 still fails to finish opening the file however. bibisection of the fix points to the range f93ce4f7eb90093d0ea3115d0a1c614612676dbdasbel..bd21a82ea4c7499dd8401687f641d44a7593dc44, which almost certainly means it's the below commit. I will build to confirm. commit 1fec67aab152e0c0ad6dd85082c50f1beff7d520 Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Sep 16 13:22:44 2014 +0100 Resolves: fdo#68967 looping layout RemoveFollowFlowLine() marks the layout invalid, but the next cycle through does everything exactly the same again. Try the same foul horror as nUnSplitted. But at least with a test-case that nails down reproducing the bug if a better fix is needed. Change-Id: Id6698bcb2364bd0253bedd4a7c313e25f705be8d
Matthew: Very interesting indeed! :-) I'll try to find some time to cherry-pick the fix on my local 4.3 sources and test it.
Confirmed by building - it does seem to have been the above commit that fixed it. Note that loading the problem file on a dbgutil build goes very slowly indeed regardless of the actual issue. (the bug manifests as a hang after the file loading progress bar has completed, while the irrelevant dbgutil slowness manifests as the the loading progress bar moving like the loser in a snail race) @Julien - if you're going to attempt a backport, perhaps you can do that on the original bug to keep the commit references in one place? I will close this one in favour of the one Caolan committed the fix against. Closing as RESOLVED - DUPLICATE of 68967 *** This bug has been marked as a duplicate of bug 68967 ***
I tried to cherry-pick but since I use debug mode, it's very too long to load, I gave up. Anyway, as Caolan himself indicated, this is indeed an ugly fix so don't think it worths it to put it on 4.3 branch.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]