Download it now!
Bug 118932 - FILEOPEN: vcllo.dll dump on first time loading of .xlsx (and slow loading then)
Summary: FILEOPEN: vcllo.dll dump on first time loading of .xlsx (and slow loading then)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: XLSX
  Show dependency treegraph
 
Reported: 2018-07-25 12:23 UTC by Timur
Modified: 2019-03-02 19:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
BT from dump (7.32 KB, text/plain)
2018-08-29 20:31 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2018-07-25 12:23:26 UTC
This bug is FILEOPEN that refers to FILESAVE Bug 118662 and attachment 143423 [details].

What I do is: 
1. run LO (Home, Start?) for the first time, without any application 
2. run procdump 
3. File-open attachment 143423 [details].
4. See that fileopen procdump happens.

Procdump command, for any single loaded LO: path\SYSINTERNALSSUITE\procdump.exe soffice.bin -h   "path\soffice.bin.dmp"

I noticed the first time fileopen with some LO version is longer than on subsequent loads, like 25 secs vs. 5 secs. 
There is no dump on multiple fileopen and filesave actions when LO is already loaded.

I don't have a good experience with fixing reported dumps, but let's try.
Comment 1 Xisco Faulí 2018-08-29 10:50:15 UTC
in

Version: 6.2.0.0.alpha0+
Build ID: 3bd8316718fdfed454c01a9c4ae6af6beb34437d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

it takes

real	0m6.335s
user	0m6.714s
sys	0m0.879s

is the slowness reproducible using LibreOffice without procdump ?
Comment 2 Xisco Faulí 2018-08-29 10:50:49 UTC
I can't reproduce it in

Versión: 6.1.0.3
Id. de compilación: efb621ed25068d70781dc026f7e9c5187a4decd1
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; 
Configuración regional: es-ES (es_ES); Calc: group threaded

either...
Comment 3 Timur 2018-08-29 14:53:34 UTC
Let's all test this as a first test after computer start, since results differ.
Comment 4 Telesto 2018-08-29 20:31:06 UTC
Created attachment 144538 [details]
BT from dump

Maybe bug 117936 (no quite sure)
Comment 5 Timur 2018-08-30 09:09:02 UTC
Since Telesto also had dump, I'll set to New. I modified the title to emphasize dump.
Telsto's backtrace has vcllo!TabitemValue::isRightAligned+c2e9 and mine vcllo!weld::Builder::weld_metric_spin_button+14417 
Can't say why they differ. 
I repro dump with yeterday's 6.2+ but also with 6.1 and at 4.3. Not with 4.2.7. Didn't compare dump reports.
Comment 6 Telesto 2018-08-30 09:30:05 UTC
(In reply to Timur from comment #5)
> Since Telesto also had dump, I'll set to New. I modified the title to
> emphasize dump.
> Telsto's backtrace has vcllo!TabitemValue::isRightAligned+c2e9 and mine
> vcllo!weld::Builder::weld_metric_spin_button+14417 
> Can't say why they differ. 
> I repro dump with yeterday's 6.2+ but also with 6.1 and at 4.3. Not with
> 4.2.7. Didn't compare dump reports.

I'm tempted to add Caolán to the loop; because of all his welding... Looking at (vcllo!weld::Builder::weld_metric_spin_button) & TabitemValue::isRightAligned (which seems to be about the widget position: https://opengrok.libreoffice.org/xref/core/include/vcl/salnativewidgets.hxx#386

and seeing this similar behaviour loop endlessly in VerySleepy for attachment 144526 [details] when saving the file (does also dump a lot). Which seems odd to me. Why processing dialog stuff while saving?

However, I'm not qualified to analyse or judge BT's :-)