Bug 46100 - Crash after deleting a sheet
Summary: Crash after deleting a sheet
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:3.7.0 target:3.6.3
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-15 05:45 UTC by underscoredje
Modified: 2012-10-08 09:36 UTC (History)
4 users (show)

See Also:


Attachments
File to use to reproduce the bug (856.45 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-15 05:45 UTC, underscoredje
Details
Bug 46100 - WinDbg session with FAILED_SOURCE_CODE (42.05 KB, text/plain)
2012-05-30 00:24 UTC, bfoman (inactive)
Details
test file with cubic splines (789.90 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-10-04 15:47 UTC, Markus Mohrhard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description underscoredje 2012-02-15 05:45:36 UTC
Created attachment 57094 [details]
File to use to reproduce the bug

To reproduce the bug:
- Open attached file
- Delete one these sheets: 4-6
- Go back on sheet 2 or 3
Spreadsheet crash
Comment 1 Ángel Luis García García 2012-04-20 12:37:20 UTC
[Reproducible] with "LibreOffice 3.5.2.2 - Windows XP Service Pack 3 Spanish UI"
Comment 2 bfoman (inactive) 2012-04-27 06:16:20 UTC
Confirmed with:
LOdev 3.5.3rc1+ 
Build ID: 51648779-22e3d74-d554af7
Windows 7 Professional SP1 64 bit
Comment 3 sasha.libreoffice 2012-05-18 07:43:49 UTC
reproduced in 3.5.3 on Fedora 64 bit. But it hangs and consumes all CPU resources, but not crashes
Comment 4 bfoman (inactive) 2012-05-30 00:24:46 UTC
Created attachment 62256 [details]
Bug 46100 - WinDbg session with FAILED_SOURCE_CODE

Confirmed with:
LO 3.5.4.2 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Attached full WinDbg session with FAILED_SOURCE_CODE.
Comment 5 Kohei Yoshida 2012-09-27 14:59:49 UTC
@bfoman: How much memory do you have installed on your system?
Comment 6 Michael Meeks 2012-10-03 15:15:55 UTC
Reproduces under linux similar trace, different place:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Program received signal SIGABRT, Aborted.
0xb7c878c5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
	in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0xb7c878c5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0xb7c891d5 in __GI_abort () at abort.c:93
#2  0xb7ec681d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3  0xb7ec45b3 in ?? () from /usr/lib/libstdc++.so.6
#4  0xb7ec32fb in ?? () from /usr/lib/libstdc++.so.6
#5  0xb7ec3da6 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#6  0xb7ddd8a3 in ?? () from /lib/libgcc_s.so.1
#7  0xb7dddcb3 in _Unwind_Resume () from /lib/libgcc_s.so.1
#8  0xb7b5c390 in comphelper::EmbeddedObjectContainer::GetGraphicReplacementStream (nViewAspect=1, xObj=
    uno::Reference to {<com::sun::star::embed::XVisualObject> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac76b8}, <No data fields>}, <com::sun::star::embed::XClassifiedObject> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac778c}, <No data fields>}, <com::sun::star::embed::XComponentSupplier> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac77ac}, <No data fields>}, <com::sun::star::embed::XStateChangeBroadcaster> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac77c4}, <No data fields>}, <com::sun::star::document::XEventBroadcaster> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac77e0}, <No data fields>}, <com::sun::star::util::XCloseable> = {<com::sun::star::util::XCloseBroadcaster> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaaac77fc}, <No data fields>}, <No data fields>}, <No data fields>}, pMediaType=0x91e4c80)
    at /data/opt/libreoffice/master/comphelper/source/container/embeddedobjectcontainer.cxx:1561

As Kohei suggests - that exception means we're out of memory - could be we do some massive allocation; or could be we leak at top speed; hard to know - I'll have a poke :-)
Comment 7 Michael Meeks 2012-10-03 15:24:51 UTC
valgrind clean => most likely some silly leak or massive allocation :-)
Comment 8 Kohei Yoshida 2012-10-03 15:27:03 UTC
My first suspicion would be the undo object for sheet delete action making tons of copies of the deleted sheet(s).
Comment 9 Michael Meeks 2012-10-03 17:00:10 UTC
We eventually throw from here:

#0  0xb7ec46d0 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1  0xab932168 in realloc (this=<optimized out>, nSize=<optimized out>)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/com/sun/star/uno/Sequence.hxx:199
#2  com::sun::star::uno::Sequence<double>::realloc (this=0xaa5cad34, nSize=63578)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/com/sun/star/uno/Sequence.hxx:188
#3  0xab977264 in chart::(anonymous namespace)::lcl_addPointToPoly (rPoly=<optimized out>, rPos=..., nPolygonIndex=584, rResultPointCount=..., 
    nReservePointCount=63578) at /data/opt/libreoffice/master/chart2/source/view/main/Clipping.cxx:183
#4  0xab9777ed in chart::Clipping::clipPolygonAtRectangle (rPolygon=..., rRectangle=..., aResult=..., bSplitPiecesToDifferentPolygons=true)
    at /data/opt/libreoffice/master/chart2/source/view/main/Clipping.cxx:268
#5  0xab945e37 in chart::AreaChart::impl_createLine (this=0x97f4e28, pSeries=0x9c3b1c0, pSeriesPoly=0x9c3b1c4, pPosHelper=0x97f4f20)
    at /data/opt/libreoffice/master/chart2/source/view/charttypes/AreaChart.cxx:310
#6  0xab946495 in chart::AreaChart::impl_createSeriesShapes (this=0x97f4e28)
    at /data/opt/libreoffice/master/chart2/source/view/charttypes/AreaChart.cxx:510
#7  0xab947cbb in chart::AreaChart::createShapes (this=0x97f4e28)

Reading up the trace; I'm interested by:

2801	void SAL_CALL ChartView::update() throw (uno::RuntimeException)
2802	{
2803	    impl_updateView();
2804	
2805	    //#i100778# migrate all imported or old documents to a plot area sizing exclusive axes (in case the save settings allow for this):
2806	    //Although in general it is a bad idea to change the model from within the view this is exceptionally the best place to do this special conversion.
2807	    //When a view update is requested (what happens for creating the metafile or displaying
(gdb) 
2808	    //the chart in edit mode or printing) it is most likely that all necessary informations are available - like the underlying spreadsheet data for example.
2809	    //Those data is important for the correct axis lable sizes which are needed during conversion.
2810	    if( DiagramHelper::switchDiagramPositioningToExcludingPositioning( m_xChartModel, true, false ) )
2811	        impl_updateView();

Why all that big comment if we're going to call impl_updateView anyway ? perhaps some merge error there ? ...
Comment 10 Michael Meeks 2012-10-04 11:07:37 UTC
Seems like we're just chewing a huge scad of memory; instrumenting:

chart2/source/view/main/Clipping.cxx (lcl_addPointToPoly)

We have three sequences of doubles for X,Y,Z point data there - we realloc those to size: 63578 - which 1/2 a Mb, we have three of these - so 1.5Mb per time we hit that. We always realloc from length 0 so looks like these are new allocations.

We then do ~1030 of these before my machine bombs: so that's 1.5GB or so from this call-site.

That sounds like rather a lot ;-)
Comment 11 Markus Mohrhard 2012-10-04 15:41:19 UTC
So after having a look at this file and playing a bit with it I have a very strong feeling that the whole problem here is the smoothing and the smoothing algorithm.

ODF 1.2 switched to b-spline as default smoothing algorithm which is set to an insane value of degree 50 polynomial in this file. Together with the large range this creates millions of points that are totally useless in the end.

Furthermore, I think that our B-spline algorithm has a bug and there is another bug report for that. I once spend some time investigating this issue but the code is not that nice and extremely complex to bring under test control.

I'll try to attach a saner version of this test document that shows that the same document can be changed to a way that will not crash with bad_alloc while still being usable.
Comment 12 Markus Mohrhard 2012-10-04 15:47:12 UTC
Created attachment 68087 [details]
test file with cubic splines

Attached the same file with cubic splines instead of b-splines.

I can delete a sheet in it with the memory consumption never going above 200 MB in a 64bit debug/dbguti build.
Comment 13 Not Assigned 2012-10-04 18:01:28 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

limit degree for b-spline to 15 to prevent std::bad_alloc, fdo#46100



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 14 Not Assigned 2012-10-04 18:23:02 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

limit polynomial degree in the dialog, related fdo#46100



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 Not Assigned 2012-10-06 17:22:38 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dd2c8ec4992516f0e6b3e4a98eda89ab8abc579&g=libreoffice-3-6

limit degree for b-spline to 15 to prevent std::bad_alloc, fdo#46100


It will be available in LibreOffice 3.6.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.
Comment 16 Not Assigned 2012-10-06 17:22:55 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e935aab070404d318d5fa2eee4bfbd1184b8d080&g=libreoffice-3-6

limit polynomial degree in the dialog, related fdo#46100


It will be available in LibreOffice 3.6.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.
Comment 17 Michael Meeks 2012-10-08 09:36:27 UTC
Pushed everywhere important => fixed.
Thanks for the report & for the nice fix Markus ! :-)