Problem description: Try opening and then saving in ods the following file http://files.sciverse.com/documents/xlsx/title_list.xlsx 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: 4.1.3.1 rc
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
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.
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?
affects Windows as well and older LibO releases too (tried with 3.6.7.2 and 4.0.4.2 under Win7 64bit)
Opened in a couple of minutes on Win 7 64-bit 4.3.2.2. Opened in a couple of seconds on dev build Version: 4.4.0.0.alpha0+ Build ID: 3e2bd1e4022e25b77bcc8eba5e02c1adc57008a1 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-16_01:04:13 Tried saving to .ods with 4.3.2.2, hangs. Tried saving to .ods with dev build, success in about 30 secs, but opening the .ods freezes LO!
--> todventtu@suomi24.fi I confirm the results of previous comment using LibO 4.3.2.2 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?
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.
@Julien 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.
tommy27: you're right, I had overlooked the saving part.
Needs merging with 56394, I guess. My fault.
@sergio does this implies this one is a duplicate of Bug 56394 ?
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).
*** This bug has been marked as a duplicate of bug 56394 ***