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
LibreOffice uses 100%, the GUI appears frozen.
The document is opened without issues.
Operating System: Debian
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
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 220.127.116.11.
Doesn't hang on dev build Version: 18.104.22.168.alpha0+
Build ID: 276a046d5256b14478ab283f420654df6ae76b55
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-08_00:21:52
Please test with 22.214.171.124 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: 126.96.36.199.alpha0+
Build ID: 8c7f6830e767897d3a0e88f75fc8d7ef7fca95dc
TinderBox: Win-x86@42, Branch:master, Time: 2015-01-06_00:47:25
Ubuntu 14.10 64-bit Version: 188.8.131.52.alpha0+
Build ID: f92183833fa569006602ac7e93c906d2094e0d4d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-12-14_00:21:45
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
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Sun Dec 9 10:01:11 2012 +0000
Author: Matúš Kukan <email@example.com>
AuthorDate: Sat May 5 14:47:15 2012 +0200
Commit: Matúš Kukan <firstname.lastname@example.org>
CommitDate: Sat May 5 16:23:10 2012 +0200
: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:
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:
This is already fixed in 184.108.40.206; 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)
220.127.116.11 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.
Author: Caolán McNamara <email@example.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.
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)