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.
Created attachment 144925 [details] ods file in question
Created attachment 144926 [details] stack trace
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.
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.
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
Created attachment 144931 [details] gdb backtrace
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
(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.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=f351fd1e8eb75a25e7844ac632e5837851b2aeed..375ee984859a3c7b03faae6ec92c50be43a39988
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
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
Created attachment 144983 [details] gdb backtrace
(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.
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.
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/
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.