Bug 876073

Summary: [abrt] libreoffice-core-3.5.6.2-5.fc17: __cxa_call_terminate from exception in rtl_byte_sequence_release
Product: [Fedora] Fedora Reporter: Pierre Blavy <pierreblavy>
Component: libreofficeAssignee: Stephan Bergmann <sbergman>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: caolanm, dtardon, erack, ltinkl, mstahl, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:20fb054507205d617699b2ecaa0914964fc4c17b
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-14 12:44:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: core_backtrace
none
File: environ
none
File: backtrace
none
File: limits
none
File: cgroup
none
File: maps
none
File: dso_list
none
File: open_fds
none
File: var_log_messages none

Description Pierre Blavy 2012-11-13 09:07:12 UTC 
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
Comment 1 Pierre Blavy 2012-11-13 09:07:39 UTC 
Created attachment 643999 [details]
File: core_backtrace
Comment 2 Pierre Blavy 2012-11-13 09:07:45 UTC 
Created attachment 644000 [details]
File: environ
Comment 3 Pierre Blavy 2012-11-13 09:07:50 UTC 
Created attachment 644001 [details]
File: backtrace
Comment 4 Pierre Blavy 2012-11-13 09:07:53 UTC 
Created attachment 644002 [details]
File: limits
Comment 5 Pierre Blavy 2012-11-13 09:07:55 UTC 
Created attachment 644003 [details]
File: cgroup
Comment 6 Pierre Blavy 2012-11-13 09:07:57 UTC 
Created attachment 644004 [details]
File: maps
Comment 7 Pierre Blavy 2012-11-13 09:08:00 UTC 
Created attachment 644005 [details]
File: dso_list
Comment 8 Pierre Blavy 2012-11-13 09:08:02 UTC 
Created attachment 644006 [details]
File: open_fds
Comment 9 Pierre Blavy 2012-11-13 09:08:04 UTC 
Created attachment 644007 [details]
File: var_log_messages
Comment 10 Stephan Bergmann 2012-11-13 09:37:49 UTC 
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).
Comment 11 Pierre Blavy 2012-11-14 09:35:03 UTC 
> 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.
Comment 12 Stephan Bergmann 2012-11-14 12:44:20 UTC 
(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.