Description of problem: Just tried to save ods document on a USB drive. Using a copy of the document on the HDD has the same result. Version-Release number of selected component: libreoffice-core-3.5.7.2-2.fc17 Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 backtrace_rating: 4 cmdline: /usr/lib/libreoffice/program/soffice.bin --calc --splash-pipe=6 crash_function: (anonymous namespace)::Parameter::getType kernel: 3.6.1-1.fc17.i686 truncated backtrace: :Thread no. 1 (10 frames) : #7 (anonymous namespace)::Parameter::getType at /usr/src/debug/libreoffice-3.5.7.2/stoc/source/registry_tdprovider/methoddescription.cxx:109 : #8 cppu::createCTD at /usr/src/debug/libreoffice-3.5.7.2/cppuhelper/source/tdmgr.cxx:366 : #10 cppu::typelib_callback at /usr/src/debug/libreoffice-3.5.7.2/cppuhelper/source/tdmgr.cxx:702 : #11 callChain at /usr/src/debug/libreoffice-3.5.7.2/cppu/source/typelib/typelib.cxx:260 : #12 typelib_typedescription_getByName at /usr/src/debug/libreoffice-3.5.7.2/cppu/source/typelib/typelib.cxx:2237 : #13 typelib_typedescriptionreference_getDescription at /usr/src/debug/libreoffice-3.5.7.2/cppu/source/typelib/typelib.cxx:2468 : #14 stoc_corefl::InterfaceIdlClassImpl::initMembers at /usr/src/debug/libreoffice-3.5.7.2/stoc/source/corereflection/criface.cxx:847 : #15 stoc_corefl::InterfaceIdlClassImpl::getFields at /usr/src/debug/libreoffice-3.5.7.2/stoc/source/corereflection/criface.cxx:908 : #16 stoc_inspect::ImplIntrospection::implInspect at /usr/src/debug/libreoffice-3.5.7.2/stoc/source/inspect/introspection.cxx:2363 : #17 stoc_inspect::ImplIntrospection::inspect(com::sun::star::uno::Any const&) at /usr/src/debug/libreoffice-3.5.7.2/stoc/source/inspect/introspection.cxx:1959
Created attachment 629300 [details] File: core_backtrace
Created attachment 629302 [details] File: environ
Created attachment 629303 [details] File: limits
Created attachment 629304 [details] File: backtrace
Created attachment 629305 [details] File: cgroup
Created attachment 629306 [details] File: maps
Created attachment 629307 [details] File: dso_list
Created attachment 629308 [details] File: var_log_messages
Created attachment 629309 [details] File: open_fds
Does just launching calc (with no document) work ? or does it just happen when you save a specific spreadsheet ? If the latter, can we get that spreadsheet ?
It happened either when opening program with no file to open or opening a file from pcmanfm. Now I'm unable to open calc, but a while ago (like 10 minutes?) I opened my spreadsheet, edited it and saved. With no problems. When trying to run LO Calc I see the splashscreen and progress bar, but after it disappears nothing happens. And lxtask doesn't show running instantion of calc. But now, after second try calc works. lol. This is crazy. Saving a file works. Also opening specific file and saving it works fine. It looks like it's not about the spreadsheet.
crashes via std::terminate... #12 typelib_typedescription_getByName is defined with SAL_THROW_EXTERN_C() which expands to "throw ()". but the RuntimeException from #7 0xb6cfbbec in (anonymous namespace)::Parameter::getType should be caught already in #10 0x4d7cb399 in cppu::typelib_callback also the exception typeinfo is clearly exported: > nm -D --demangle /usr/lib64/libreoffice/ure/lib/libuno_cppuhelpergcc3.so.3 | grep RuntimeException 0000003ccdeb9980 V typeinfo for com::sun::star::uno::RuntimeException 0000003ccdebbeb0 V typeinfo for com::sun::star::lang::WrappedTargetRuntimeException 0000003ccdc9b940 V typeinfo name for com::sun::star::uno::RuntimeException 0000003ccdc9f840 V typeinfo name for com::sun::star::lang::WrappedTargetRuntimeException > nm -D --demangle /usr/lib64/libreoffice/ure/lib/bootstrap.uno.so | grep RuntimeException 00000000002ba0b0 V typeinfo for com::sun::star::uno::RuntimeException 00000000002c2a80 V typeinfo for com::sun::star::uno::RuntimeException* 0000000000097740 V typeinfo name for com::sun::star::uno::RuntimeException 000000000009e260 V typeinfo name for com::sun::star::uno::RuntimeException* don't understand what's going on there.
Turned out the problem was (a hard to spot) throwing a UNO exception by pointer in C++ code. Audited the code for that problem, found and fixed a handful of instances.
libreoffice-4.0.3.1-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libreoffice-4.0.3.1-2.fc19
libreoffice-3.6.6.2-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libreoffice-3.6.6.2-5.fc18
Package libreoffice-3.6.6.2-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-3.6.6.2-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6396/libreoffice-3.6.6.2-5.fc18 then log in and leave karma (feedback).
libreoffice-4.0.3.1-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libreoffice-3.6.6.2-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.