Bug 92198 - FILEOPEN: CPU at 100% after opening file (links problem)
Summary: FILEOPEN: CPU at 100% after opening file (links problem)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other Linux (All)
: medium major
Assignee: Markus Mohrhard
URL:
Whiteboard: target:5.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: RenderContext
  Show dependency treegraph
 
Reported: 2015-06-20 05:54 UTC by raal
Modified: 2016-10-25 19:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Spreadsheet after delete links with 4.3 (326.35 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2015-06-24 17:57 UTC, m.a.riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description raal 2015-06-20 05:54:59 UTC
Steps to reproduce:
open attechment from bug 92193 , https://bugs.documentfoundation.org/attachment.cgi?id=116664

actual results:
LO uses cpu at 100%, file is unusable

expected results:
LO open file

regression, because I can open file in LO 4.3.7 and reporter of the bug 92193 can open this file in LO 5.0 beta3
Comment 1 m.a.riosv 2015-06-20 13:52:19 UTC
Hi @raal,

I can reproduce.
Win7x64Ultimate
Version: 5.1.0.0.alpha1+ Build ID: d56b125f6c6c18ac40712cefc3cec06530750e15
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-13_07:08:43

Perhaps the issue is in relation with links.

Please try this:

Open the file with 4.3.
Menu/Edit/Links, and break all links.
Save the file
Open with 5.1.
Links are there again (I don't investigate why, maybe are created with formulas), but the issue has disappear.
Comment 2 raal 2015-06-24 16:21:06 UTC
(In reply to m.a.riosv from comment #1)

Hi, still the same, even after deleting links (two links are back after deleting) . Setting to NEW, confirmed in comment 1.
Comment 3 m.a.riosv 2015-06-24 17:57:54 UTC
Created attachment 116811 [details]
Spreadsheet after delete links with 4.3

(In reply to raal from comment #2)
Hi, the original file shows the issue but the file after deleting links with 4.3 (attached) not for me.

Version: 5.1.0.0.alpha1+ (x64)
Build ID: a51ac4d2bb8c4f1ea1d4ea7569863e2fb6535b02
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-06-22_21:37:53

I'm able to find where the links are.

No direct links ('file:' not founded in the whole sheets), no named ranges with links, no data ranges.

I think time ago, I needed to modify directly a file to delete some links.

Hiperlinks are in the sheets with data in AE4, that maybe are not intentional and as they are stored in the original file provoke the issue in 5.1.
Comment 4 raal 2015-06-24 20:34:18 UTC
(In reply to m.a.riosv from comment #3)
> Created attachment 116811 [details]
> Spreadsheet after delete links with 4.3
> 
Click to sheet "BDBD". I can open your file and it works, but when I click into sheet BDBD, I have CPU at 100% again..
Comment 5 Michael Meeks 2015-07-03 17:01:26 UTC
This looks problematic:

Breakpoint 1, vcl::Window::ImplInvalidate (this=0x17b764d0, pRegion=0x7fffffffb990, nFlags=NONE) at /data/opt/libreoffice/master/vcl/source/window/paint.cxx:719
719	    if ( mpWindowImpl->mpFrameData->mpFirstBackWin )
(gdb) bt
#0  vcl::Window::ImplInvalidate (this=0x17b764d0, pRegion=0x7fffffffb990, nFlags=NONE) at /data/opt/libreoffice/master/vcl/source/window/paint.cxx:719
#1  0x00007ffff071fdd5 in vcl::Window::Invalidate (this=0x17b764d0, rRect=Rectangle = {...}, nFlags=NONE) at /data/opt/libreoffice/master/vcl/source/window/paint.cxx:1170
#2  0x00007fffc21db82c in ScTabView::PaintArea (this=0x1ba4da58, nStartCol=0, nStartRow=7, nEndCol=1023, nEndRow=7, eMode=SC_UPDATE_ALL) at /data/opt/libreoffice/master/sc/source/ui/view/tabview3.cxx:2015
#3  0x00007fffc21f96c6 in ScTabViewShell::Notify (this=0x1ba4d9f0, rBC=..., rHint=...) at /data/opt/libreoffice/master/sc/source/ui/view/tabvwsh5.cxx:153
#4  0x00007ffff34d0410 in SfxBroadcaster::Broadcast (this=0x1485b30, rHint=...) at /data/opt/libreoffice/master/svl/source/notify/SfxBroadcaster.cxx:51
#5  0x00007fffc1d6b965 in ScDocShell::PostPaint (this=0x1485b30, rRanges=..., nPart=1, nExtFlags=0) at /data/opt/libreoffice/master/sc/source/ui/docshell/docsh3.cxx:161
#6  0x00007fffc1d6b575 in ScDocShell::PostPaint (this=0x1485b30, nStartCol=4, nStartRow=7, nStartTab=15, nEndCol=4, nEndRow=7, nEndTab=15, nPart=1, nExtFlags=0) at /data/opt/libreoffice/master/sc/source/ui/docshell/docsh3.cxx:95
#7  0x00007fffc1d77c06 in ScDocShell::DoAutoStyle (this=0x1485b30, rRange=..., rStyle="LightBlueBg") at /data/opt/libreoffice/master/sc/source/ui/docshell/docsh4.cxx:1289
#8  0x00007fffc1d1a42a in ScAutoStyleList::InitHdl (this=0x17b3b40) at /data/opt/libreoffice/master/sc/source/ui/docshell/autostyl.cxx:109
#9  0x00007fffc1d1a37b in ScAutoStyleList::LinkStubInitHdl (instance=0x17b3b40, data=0x17b3b88) at /data/opt/libreoffice/master/sc/source/ui/docshell/autostyl.cxx:103
#10 0x00007ffff0722f0b in Link<Idle*, void>::Call (this=0x17b3ba8, data=0x17b3b88) at /data/opt/libreoffice/master/include/tools/link.hxx:127
#11 0x00007ffff0ccf905 in Idle::Invoke (this=0x17b3b88) at /data/opt/libreoffice/master/vcl/source/app/idle.cxx:26

An Invalidate called from a Paint method seems non-ideal - but perhaps I'm confused =)
Comment 6 Michael Weghorn 2015-07-17 19:21:43 UTC
bibisect result:

There are only 'skip'ped commits left to test.
The first bad commit could be any of: 891b689ba95b9e53609194ee2a1a2d3b8955843c 18afb8632caa524fbc70ed5ce3808e23e5dad16f
We cannot bisect more!

---

$ git bisect log
# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# good: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect good 0c30a2c797b249d0cd804cb71554946e2276b557
# bad: [2ce02b2ce56f12b9fcb9efbd380596975a3a5686] source-hash-17d714eef491bda2512ba8012e5b3067ca19a5be
git bisect bad 2ce02b2ce56f12b9fcb9efbd380596975a3a5686
# bad: [e4deb8a42948865b7b23d447c1547033cb54535b] source-hash-ce46c98dbeb3364684843daa5b269c74fce2af64
git bisect bad e4deb8a42948865b7b23d447c1547033cb54535b
# bad: [15e8b5cc6b4784fecd63b2a5a04ac086b3e9fc01] source-hash-26b500afcaed704db7a300836f466517c309ee77
git bisect bad 15e8b5cc6b4784fecd63b2a5a04ac086b3e9fc01
# bad: [534715525a93b0d7d56ba123d253c927cccf0afe] source-hash-40c9a46b78b8919aae82dd9b94774d63bb9cb4e6
git bisect bad 534715525a93b0d7d56ba123d253c927cccf0afe
# good: [c255ade961c9628f72d2fbca268fdf3a4e5f60c2] source-hash-4bdbea5447f36beb9cc33df173a89a49a9918290
git bisect good c255ade961c9628f72d2fbca268fdf3a4e5f60c2
# good: [2b4739cd51404149b1279b86643f1fee719de667] source-hash-8ee20e2691aa6f67c67d40c61a8cd1569458b5a8
git bisect good 2b4739cd51404149b1279b86643f1fee719de667
# good: [9891e7d487540e4650378e546aea5025876d02cf] source-hash-b2f76e0e8a81b456f47b677cd881cc105f781cdb
git bisect good 9891e7d487540e4650378e546aea5025876d02cf
# skip: [891b689ba95b9e53609194ee2a1a2d3b8955843c] source-hash-01f406bc28f53acc5a2734af637aa8074a5d1813
git bisect skip 891b689ba95b9e53609194ee2a1a2d3b8955843c
# good: [4484ce03daa4db83ee9ce6e54396d6f1a0ddcb2a] source-hash-6a3c5af4eb96d03110fcbc856c6920bfcf4063c7
git bisect good 4484ce03daa4db83ee9ce6e54396d6f1a0ddcb2a
# bad: [18afb8632caa524fbc70ed5ce3808e23e5dad16f] source-hash-d05a64df34fd143670cb939b72abfb32d6b714c7
git bisect bad 18afb8632caa524fbc70ed5ce3808e23e5dad16f
# good: [b02369ea724c86023b074987f04fd60f956c4618] source-hash-4cd7b4ab8aeaf61f5e30e4b63e039b7bb9519e85
git bisect good b02369ea724c86023b074987f04fd60f956c4618
# good: [b52e9a820cbacc502e51aeae755415ea1ac8994a] source-hash-100c518e980f6abdc93c727c524b738200236bf2
git bisect good b52e9a820cbacc502e51aeae755415ea1ac8994a
# good: [cfa6015c1d535c8e22bef6a6abb9363c757693d1] source-hash-9e678c14e4fc8e58b1e0530744f648fa3958d338
git bisect good cfa6015c1d535c8e22bef6a6abb9363c757693d1
# only skipped commits left to test
# possible first bad commit: [18afb8632caa524fbc70ed5ce3808e23e5dad16f] source-hash-d05a64df34fd143670cb939b72abfb32d6b714c7
# possible first bad commit: [891b689ba95b9e53609194ee2a1a2d3b8955843c] source-hash-01f406bc28f53acc5a2734af637aa8074a5d1813

The skipped commit gave "ERROR 4 forking process" for me on Debian Jessie.
Comment 7 Michael Weghorn 2015-07-17 19:23:02 UTC
Tobi, you are the author of both commits in question. Could you possibly have a look at this?
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:13:16 UTC Comment hidden (obsolete)
Comment 9 Markus Mohrhard 2016-04-10 14:12:49 UTC
Looks like another STYLE in conditional formatting problem.
Comment 10 Commit Notification 2016-04-10 14:37:12 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=28d0e255e231639c4d79f6dedbe972d6daeae7f0

tdf#94429, tdf#92198, tdf#95233: STYLE in conditional formatting

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.
Comment 11 Markus Mohrhard 2016-04-10 14:40:19 UTC
I'm still going to either remove STYLE in conditional format formulas or limit it to the 1 parameter version as part of 5.3.

This is an ugly hack for 5.2.