Bug 99655 - LO Calc gets stuck when inserting a new sheet from certain existing sheets
Summary: LO Calc gets stuck when inserting a new sheet from certain existing sheets
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected
Depends on:
Blocks: Sheet
  Show dependency treegraph
Reported: 2016-05-03 16:10 UTC by Mamoth
Modified: 2022-08-10 10:50 UTC (History)
4 users (show)

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

File with the problem (see description) (4.78 MB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-03 16:10 UTC, Mamoth
Second file with which the bug occurs (5.70 MB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-09 10:12 UTC, Mamoth
some frames 'finish'ing in gdb don't really finish ... (17.06 KB, text/plain)
2016-06-30 12:17 UTC, Michael Meeks

Note You need to log in before you can comment on or make changes to this bug.
Description Mamoth 2016-05-03 16:10:52 UTC
Created attachment 124820 [details]
File with the problem (see description)

I just encountered a curious problem : I have an existing file (attached).

LO Calc gets stuck (with the CPU getting over the roof to 100% according to a 'top' command in a terminal) if I try to insert a new sheet while I currently am with the existing sheet 'Données horaires traitées' open.

But if I attempt to do the same thing with open sheet being 'INSTRUCTIONS', it works fine.

I suppose it is connected that there is a lot of rows with calculations in the sheet  'Données horaires traitées' and not in the sheet 'INSTRUCTIONS'.
Comment 1 raal 2016-05-04 06:37:36 UTC
This file crash LO when loading - Version:; win7
I can open file in
Comment 2 Mamoth 2016-05-04 07:51:01 UTC
Just as complement of information, let me add that the version of Linux I use is Linux Mint 17.3 (originally an install of 17.1 but upgraded).
Comment 3 raal 2016-05-04 08:52:39 UTC
The crash of LO when loading - This seems to have begun at the below commit.
Adding Cc: to Tomaž Vajngerl; Could you possibly take a look at this one? Thanks
 97d366b4fa31a6aab550dbe001a893c4dd0e5bc3 is the first bad commit
commit 97d366b4fa31a6aab550dbe001a893c4dd0e5bc3
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sat Apr 23 11:43:22 2016 -0700

    source sha:334e2dc9c3da4519e31e0452a40d3a958c401876

    source sha:334e2dc9c3da4519e31e0452a40d3a958c401876

:040000 040000 c13e408787ecb466a4188c9d9542f874625c2882 5a4699218d1c6dc6c60a4b802c613ac207dea93d M      instdir

author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2016-04-20 13:19:47 (GMT)
committer	Tomaž Vajngerl <quikee@gmail.com>	2016-04-22 11:27:05 (GMT)
commit 334e2dc9c3da4519e31e0452a40d3a958c401876 (patch)
tree bfe420e41e0e9c5e7767c4ce657bd5e29192d91f
parent cb5438a3d16634eb267584122169758ab2b76930 (diff)
opencl: better logging of devices and device selection

Original bug no repro in, win7 - I can insert new sheet.
Mamoth, what's your version of LO?
Comment 4 Mamoth 2016-05-09 10:09:23 UTC

I have found another file with which I have the same issue. See new attachment 

I you position yourself on the sheet 'Évènements' open and ass a new sheet (by clicking the '+' button at the left end of the tabs menu at the bottom of the LO window), it works fine.

Now, if you attempt to do the same thing from the sheet 'Agrégats départs triphasés' open, LO gets stuck and killing the process is the only way to recover from this situation.

This was tested with LO version under Linux Mint 17.3.
Comment 5 Mamoth 2016-05-09 10:12:14 UTC
Created attachment 124927 [details]
Second file with which the bug occurs
Comment 6 Michael Meeks 2016-06-30 12:17:29 UTC
Loads for me - but (very) slowly - takes > 1 minute with a debug-build; I get one progress bar over the top of another one too which is interesting. Takes 5s to switch to the mentioned sheet too =)

I guess the weight of this sheet - and re-writing the formualae is the problem; nothing to do with OpenCL. I attach a trace of its behaviour on my Linux machine highlighting the slow pieces.

Thanks !
Comment 7 Michael Meeks 2016-06-30 12:17:58 UTC
Created attachment 125999 [details]
some frames 'finish'ing in gdb don't really finish ...
Comment 8 Eike Rathke 2016-12-01 14:17:33 UTC
Inserting a sheet as described takes ~6s on a fairly fast laptop. 70% of the time is spent under EndListening(). Taking.
Though the crash during load mentioned above is completely unrelated and should had been a separate bug. Removing regression keyword here.
Comment 9 Eike Rathke 2016-12-05 19:56:41 UTC
I'm returning this to the pool. Or actually I think this should be resolved as "works now". I don't see it getting stuck (see last comment). 70% time spent is under EndListening() SfxBroadcaster::Remove() the memmove within std::vector, but there is no real solution to that (tests using a std::list instead made things even slower due to the heap alloc overhead). Unless someone comes up with a beautiful idea how to reorder listeners such that they need to be removed from the end only so there'd be no memmove needed..
Comment 10 QA Administrators 2018-07-16 02:42:01 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2020-07-16 03:44:32 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2022-07-17 03:30:29 UTC Comment hidden (obsolete)
Comment 13 Timur 2022-08-10 10:50:48 UTC
With LO 5.2 I insert in 10 secs, but with 7.2 faster, in 2 sec. 
Not instant but acceptable. 
Per comment 9 I close as WFM.