Bug 70867 - FILEOPEN: FILESAVE: LibO takes 20 min to open .xlsx (RESOLVED) and then can't save it as .ods (still NEW)
Summary: FILEOPEN: FILESAVE: LibO takes 20 min to open .xlsx (RESOLVED) and then can't...
Status: RESOLVED DUPLICATE of bug 56394
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2013-10-25 16:58 UTC by Callegar
Modified: 2014-11-06 18:25 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2013-10-25 16:58:39 UTC
Problem description:

Try opening and then saving in ods the following file


On my machine it took > 20 mins to open. Then it's now > 40' I'm waiting for it to be saved in ods. Still the file has not even made its appearance on the filesystem.

Apache Openoffice and does not seem to do better, though.
Operating System: Ubuntu
Version: rc
Comment 1 Cor Nouws 2013-10-25 22:09:37 UTC
Hi Sergio,

thanks for the sample. I tried in a master build, and quited after 10 minutes. Looks as a full freeze to me..

(Could try in previous versions to check ??)
Cheers - Cor
Comment 2 Callegar 2013-10-25 22:30:02 UTC
Tried about one year ago (2012) with the version of the same doc that was up at that time and the LO that was current at that time. It was about the same.

The funny thing is that it is not a freeze. You just need to leave the application enough time to run with one cpu core at 100%...

If you succeed in saving as ods, then things get a bit better from that moment on.
Comment 3 Julien Nabet 2013-10-25 22:31:36 UTC
On pc Debian x86-64 with master sources updated today, it seems I've got the same during opening (yet I didn't wait for 20 min).

Here's a part of bt at random:
0x00002aaaae267043 in rtl::OUString::equals (this=0x4504a18, str="40% - Accent2 3 3 4 4") at /home/julien/compile-libreoffice/libo/include/rtl/ustring.hxx:507
507	        if ( pData->length != str.pData->length )
(gdb) bt
#0  0x00002aaaae267043 in rtl::OUString::equals (this=0x4504a18, str="40% - Accent2 3 3 4 4") at /home/julien/compile-libreoffice/libo/include/rtl/ustring.hxx:507
#1  0x00002aaaae2670cb in rtl::operator== (rStr1="20% - Accent2 9 4 2", rStr2="40% - Accent2 3 3 4 4") at /home/julien/compile-libreoffice/libo/include/rtl/ustring.hxx:1149
#2  0x00002aaaae2b1bd1 in SfxStyleSheetIterator::Find (this=0x7ffffffed050, rStr="40% - Accent2 3 3 4 4")
    at /home/julien/compile-libreoffice/libo/svl/source/items/style.cxx:504
#3  0x00002aaaae2b25b0 in SfxStyleSheetBasePool::Make (this=0x1b1e3c0, rName="40% - Accent2 3 3 4 4", eFam=SFX_STYLE_FAMILY_PARA, mask=32768)
    at /home/julien/compile-libreoffice/libo/svl/source/items/style.cxx:634
#4  0x00002aaac851f93b in ScStyleSheetPool::Make (this=0x1b1e3c0, rName="40% - Accent2 3 3 4 4", eFam=SFX_STYLE_FAMILY_PARA, mask=32768)
    at /home/julien/compile-libreoffice/libo/sc/source/core/data/stlpool.cxx:105
#5  0x00002aaadc5d198f in oox::xls::CellStyle::createCellStyle (this=0x3248870) at /home/julien/compile-libreoffice/libo/sc/source/filter/oox/stylesbuffer.cxx:2669
#6  0x00002aaadc5d1a7a in oox::xls::CellStyle::finalizeImport (this=0x3248870, rFinalName="40% - Accent2 3 3 4 4")
    at /home/julien/compile-libreoffice/libo/sc/source/filter/oox/stylesbuffer.cxx:2684
#7  0x00002aaadc5e9e6e in boost::_mfi::mf1<void, oox::xls::CellStyle, rtl::OUString const&>::operator() (this=0x7ffffffed500, t=..., a1="40% - Accent2 3 3 4 4")
    at /home/julien/compile-libreoffice/libo/workdir/unxlngx6/UnpackedTarball/boost/boost/bind/mem_fn_template.hpp:186
#8  0x00002aaadc5e888d in boost::_bi::list2<boost::arg<2>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, oox::xls::CellStyle, rtl::OUString const&>, boost::_bi::list2<rtl::OUString const&, oox::xls::CellStyle&> > (this=0x7ffffffed510, f=..., a=...)
    at /home/julien/compile-libreoffice/libo/workdir/unxlngx6/UnpackedTarball/boost/boost/bind/bind.hpp:313
#9  0x00002aaadc5e606a in boost::_bi::bind_t<void, boost::_mfi::mf1<void, oox::xls::CellStyle, rtl::OUString const&>, boost::_bi::list2<boost::arg<2>, boost::arg<1> > >::operator()<rtl::OUString, oox::xls::CellStyle> (this=0x7ffffffed500, a1="40% - Accent2 3 3 4 4", a2=...)
    at /home/julien/compile-libreoffice/libo/workdir/unxlngx6/UnpackedTarball/boost/boost/bind/bind_template.hpp:76
#10 0x00002aaadc5e1b7c in oox::RefMap<rtl::OUString, oox::xls::CellStyle, oox::xls::IgnoreCaseCompare>::ForEachFunctorWithKey<boost::_bi::bind_t<void, boost::_mfi::mf1<void, oox::xls::CellStyle, rtl::OUString const&>, boost::_bi::list2<boost::arg<2>, boost::arg<1> > > >::operator() (this=0x7ffffffed500, rValue=...)
    at /home/julien/compile-libreoffice/libo/include/oox/helper/refmap.hxx:169

Kohei/Eike/Markus: one for you?
Comment 4 tommy27 2013-12-28 23:36:31 UTC
affects Windows as well and older LibO releases too (tried with and under Win7 64bit)
Comment 5 Buovjaga 2014-10-20 06:47:02 UTC
Opened in a couple of minutes on Win 7 64-bit
Opened in a couple of seconds on dev build Version:
Build ID: 3e2bd1e4022e25b77bcc8eba5e02c1adc57008a1
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-16_01:04:13

Tried saving to .ods with, hangs.
Tried saving to .ods with dev build, success in about 30 secs, but opening the .ods freezes LO!
Comment 6 tommy27 2014-10-20 09:16:57 UTC
--> todventtu@suomi24.fi
I confirm the results of previous comment using LibO under Win7x64 but I have no 4.4 master here available.

so at least there's sensible improvement of the FILEOPEN side of the bug which could be labeled as RESOLVED (expecially considering the good 4.4.x performance you report) whilst the FILESAVE issue is still present

edited summary notes to reflect the current bug situation

--> Julien Nabet
could you please give us an update about the Linux status of the bug?
Comment 7 Julien Nabet 2014-10-20 17:51:54 UTC
On pc Debian x86-64 with 4.3.2 LO Debian package, it indeed opens quickly.

Following comments from Todventu and Tommy27, let's put this one to WFM.
Comment 8 tommy27 2014-10-20 18:32:31 UTC
ok but the filesave bug is still present. see summary notes.

maybe we should split the bug and create a new report about that or reopen this one until the filesave issue is gone to.
Comment 9 Julien Nabet 2014-10-20 18:41:49 UTC
tommy27: you're right, I had overlooked the saving part.
Comment 10 Callegar 2014-11-06 16:20:44 UTC
Needs merging with 56394, I guess. My fault.
Comment 11 tommy27 2014-11-06 17:01:53 UTC
does this implies this one is a duplicate of Bug 56394 ?
Comment 12 Callegar 2014-11-06 17:11:38 UTC
Yes, and I apologize, since it was me to create the noise.  I first reported the issue in 2012 as 56394, then I evidently lost memory of it and reopened it in 2013... with the same test case... too bad (well, actually the test case is a moving target since on sciverse they update the file title_list adding new entries every now and then).
Comment 13 tommy27 2014-11-06 18:25:15 UTC

*** This bug has been marked as a duplicate of bug 56394 ***