Download it now!
Bug 119922 - calc crashes on opening this specific file
Summary: calc crashes on opening this specific file
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3 all versions
Hardware: All All
: high major
Assignee: Markus Mohrhard
URL:
Whiteboard: target:6.2.0 target:6.1.3
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2018-09-17 05:29 UTC by Ian Huang
Modified: 2018-09-25 13:31 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
ods file in question (40.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-09-17 05:30 UTC, Ian Huang
Details
stack trace (34.10 KB, text/x-log)
2018-09-17 05:30 UTC, Ian Huang
Details
gdb backtrace (17.94 KB, text/plain)
2018-09-17 10:10 UTC, Xisco Faulí
Details
Same file saved with LibreOffice 4.2 not crashing (46.72 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-09-17 10:20 UTC, Xisco Faulí
Details
gdb backtrace (7.86 KB, text/plain)
2018-09-18 11:26 UTC, Noel Grandin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Huang 2018-09-17 05:29:51 UTC
Description:
Hi, I'm not sure what it was, but somehow I've created a calc file that deterministically crashes LibreOffice calc on open.

Steps to Reproduce:
Don't really know how to describe the STR for this problem, but I managed to reproduce it after I made a "power" fit on a certain graph (which I've done successfully before). Then, the graph started glitching out and eventually the program crashed.
Reproducible with OpenCL on and off.

Actual Results:
LibreOffice now completely refuses to open it. Stack trace attached.

Expected Results:
Not ... crashed.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
I'll attach the .ods file below. I know it's likely that this is simply a case of corruption in the file itself, but given that it was created and handled by LibreOffice the whole time I figured I might as well post it and see what everyone thinks. I'm happy to close this if it's deemed a lost cause.
Comment 1 Ian Huang 2018-09-17 05:30:27 UTC
Created attachment 144925 [details]
ods file in question
Comment 2 Ian Huang 2018-09-17 05:30:51 UTC
Created attachment 144926 [details]
stack trace
Comment 3 Ian Huang 2018-09-17 05:36:24 UTC
Huh, Google Drive can preview it but Google Sheets says it's corrupted. Meaning that the corruption is probably within one of the graph elements or something.
I'm starting to think it was silly to file this bug, as dealing with file corruption is probably a wild goose chase. Just say the word and I'll close.
Comment 4 MM 2018-09-17 09:08:16 UTC
Confirmed on ubuntu 16.04 with Version: 6.2.0.0.alpha0+
Build ID: 2789bbfd607240f260dfb38b6e9c19c9cf49fca9
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-09_22:35:03
Locale: en-US (en_US.UTF-8); Calc: threaded

crashreport.libreoffice.org/stats/crash_details/33949405-4d6a-4066-a996-a7d572ac2faf

I've managed it to convert to xls and open, so it's not that broken then.

Unconfirmed on windows 7 x64 with LibreOffice 3.3.4 
OOO330m19 (Build:401)

No problem at all opening in this version.
Comment 5 Xisco Faulí 2018-09-17 10:00:26 UTC
Also reproduced in

Versión: 6.1.1.2
Id. de compilación: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; 
Configuración regional: es-ES (es_ES); Calc: group threaded
Comment 6 Xisco Faulí 2018-09-17 10:10:09 UTC
Created attachment 144931 [details]
gdb backtrace
Comment 7 Xisco Faulí 2018-09-17 10:20:29 UTC
Created attachment 144932 [details]
Same file saved with LibreOffice 4.2 not crashing

If I open the file with LibreOffice 4.2 ( doesn't crash ) and save it, then I can open it with recent versions of LibreOffice
Comment 8 MM 2018-09-17 12:45:50 UTC
(In reply to Xisco Faulí from comment #7)
> Created attachment 144932 [details]
> Same file saved with LibreOffice 4.2 not crashing
> 
> If I open the file with LibreOffice 4.2 ( doesn't crash ) and save it, then
> I can open it with recent versions of LibreOffice

Yes, but also part of the charts are missing, so it might be not a good example.
Comment 10 Xisco Faulí 2018-09-17 14:50:11 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d442a6460f5f1c897358a0e51727c90cd6746ae2

author	Noel Grandin <noel@peralex.com>	2014-03-03 14:06:44 +0200
committer	Noel Grandin <noel@peralex.com>	2014-03-11 08:18:14 +0200
commit	d442a6460f5f1c897358a0e51727c90cd6746ae2 (patch)
tree	a3e46551b4664ef057f4ee420690ce8172dd1373
parent	ea2fb5f8f9ea44d7da5f9d34760e470d696f587d (diff)
svx: sal_Bool->bool

Bisected with: bibisect-43max

Adding Cc: to Noel Grandin

I'm not 100% the commit mentioned above is the culprit one, that's why I've also bisected it with lo-linux-dbgutil-daily-till43, which also points to the same range of commits...

(In reply to Xisco Faulí from comment #9)
> Regression introduced in range
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=f351fd1e8eb75a25e7844ac632e5837851b2aeed..
> 375ee984859a3c7b03faae6ec92c50be43a39988
Comment 11 Noel Grandin 2018-09-18 11:26:33 UTC
The actual problem here is that we are trying to allocate a regression curve with nPointCount=625001323, which throws a std::bad_alloc, which gets munged a little bit by the event loop catch block for some reason.

Attached a backtrace.

Which means the most likely culprit commit is this one:

   https://cgit.freedesktop.org/libreoffice/core/commit/?id=4c7116413af091a30f5fa60c63d29bc694730518

  committer  Markus Mohrhard <markus.mohrhard@googlemail.com>
  fix odf validation errors around new chart regression curves


I'm guessing that this file is broken, and the above commit improved things by allowing us to try and load bad data, which we would formerly ignore, which causes the allocation exception
Comment 12 Noel Grandin 2018-09-18 11:26:59 UTC
Created attachment 144983 [details]
gdb backtrace
Comment 13 Markus Mohrhard 2018-09-24 23:30:44 UTC
(In reply to Noel Grandin from comment #11)
> The actual problem here is that we are trying to allocate a regression curve
> with nPointCount=625001323, which throws a std::bad_alloc, which gets munged
> a little bit by the event loop catch block for some reason.
> 
> Attached a backtrace.
> 
> Which means the most likely culprit commit is this one:
> 
>   
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=4c7116413af091a30f5fa60c63d29bc694730518
> 
>   committer  Markus Mohrhard <markus.mohrhard@googlemail.com>
>   fix odf validation errors around new chart regression curves
> 
> 
> I'm guessing that this file is broken, and the above commit improved things
> by allowing us to try and load bad data, which we would formerly ignore,
> which causes the allocation exception

It is more complicated than this. The file contains entries for loext:regression-extrapolate-forward="99999999" which can not be read by old LibreOffice files which explains why it does not crash there.

This is most likely a user input but I think we need to sanitize these values in the regression calculator to get some sensible results.
Comment 14 Commit Notification 2018-09-25 00:55:43 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

tdf#119922, sanitize the point count when extrapolate is used

It will be available in 6.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 15 Xisco Faulí 2018-09-25 09:12:47 UTC
Verified in

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

@Markus, thanks for fixing this!

Cherry-picked to 6-1 -> https://gerrit.libreoffice.org/#/c/60963/
Comment 16 Commit Notification 2018-09-25 13:31:12 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=07c710d86d99297061269a40a3b9f266b92e434a&h=libreoffice-6-1

tdf#119922, sanitize the point count when extrapolate is used

It will be available in 6.1.3.

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.