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
[Reproducible] with "LibreOffice 3.5.2.2 - Windows XP Service Pack 3 Spanish UI"
Confirmed with: LOdev 3.5.3rc1+ Build ID: 51648779-22e3d74-d554af7 Windows 7 Professional SP1 64 bit
reproduced in 3.5.3 on Fedora 64 bit. But it hangs and consumes all CPU resources, but not crashes
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.
@bfoman: How much memory do you have installed on your system?
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 :-)
valgrind clean => most likely some silly leak or massive allocation :-)
My first suspicion would be the undo object for sheet delete action making tons of copies of the deleted sheet(s).
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 ? ...
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 ;-)
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.
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.
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.
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.
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.
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.
Pushed everywhere important => fixed. Thanks for the report & for the nice fix Markus ! :-)