Version-Release number of selected component: libreoffice-core-3.5.6.2-5.fc17 Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 backtrace_rating: 4 cmdline: /usr/lib64/libreoffice/program/soffice.bin --headless --invisible --nocrashreport --nodefault --nofirststartwizard --nologo --norestore --accept=socket,host=localhost,port=2002;urp;StarOffice.ComponentContext crash_function: __cxa_call_terminate kernel: 3.5.6-1.fc17.x86_64 truncated backtrace: :Thread no. 1 (8 frames) : #4 __cxa_call_terminate at ../../../../libstdc++-v3/libsupc++/eh_call.cc:56 : #5 __cxxabiv1::__gxx_personality_v0 at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:665 : #6 _Unwind_RaiseException_Phase2 at ../../../libgcc/unwind.inc:62 : #7 _Unwind_Resume at ../../../libgcc/unwind.inc:230 : #8 ~ByteSequence at /usr/src/debug/libreoffice-3.5.6.2/solver/unxlngx6.pro/inc/rtl/byteseq.hxx:100 : #9 uno_threadpool_putJob at /usr/src/debug/libreoffice-3.5.6.2/cppu/source/threadpool/threadpool.cxx:481 : #10 binaryurp::Reader::readMessage at /usr/src/debug/libreoffice-3.5.6.2/binaryurp/source/reader.cxx:411 : #11 binaryurp::Reader::run at /usr/src/debug/libreoffice-3.5.6.2/binaryurp/source/reader.cxx:144
Created attachment 643999 [details] File: core_backtrace
Created attachment 644000 [details] File: environ
Created attachment 644001 [details] File: backtrace
Created attachment 644002 [details] File: limits
Created attachment 644003 [details] File: cgroup
Created attachment 644004 [details] File: maps
Created attachment 644005 [details] File: dso_list
Created attachment 644006 [details] File: open_fds
Created attachment 644007 [details] File: var_log_messages
Can you reproduce this, or at least explain what you were doing with the headless soffice? What apparently happens is that ~rtl::ByteSequence/rtl_byte_sequence_release tries to throw an exception that can't pass past the SAL_THROW(())/SAL_THROW_EXTERN_C(). The only reason I could imagine it to throw an exception in the first place would be some sort of memory corruption (which might lead to the code searching for nonexistent information about some bogus UNO member type for the sequence).
> Can you reproduce this? It hasn't happen spontaneously again, so no. I'll post here if I get this bug a second time. > explain what you were doing with the headless soffice? I'm not sure, but I was probably using unoconv to convert an openoffice document to a pdf. Your explanantion about memory may be true. I had others bugs at the same moment : yum corrupted its own database and crashes, java print red squares instead of icons and stuff just went wrong until i restart my computer. Unoconv conversion to pdf is a little bit random : - The first attempt to call unoconv always fail, but just typing the command line twice is a workaround. - On some very rares occasions, unoconv crashes randomly. When it happen typing again the commandline is a workaround.
(In reply to comment #11) > It hasn't happen spontaneously again, so no. I'll post here if I get this > bug a second time. > > Your explanantion about memory may be true. I had others > bugs at the same moment : yum corrupted its own database and crashes, java > print red squares instead of icons and stuff just went wrong until i restart > my computer. So closing this for now. Feel free to reopen if it occurs again.