Bug 928568 - [abrt] libreoffice-core-3.6.5.2-6.fc18: acquire: Process /usr/lib64/libreoffice/program/soffice.bin was killed by signal 11 (SIGSEGV)
Summary: [abrt] libreoffice-core-3.6.5.2-6.fc18: acquire: Process /usr/lib64/libreoffi...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephan Bergmann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:ddc55feb833cfb6a395a0ed07ac...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-28 00:03 UTC by Jonathan Nicol
Modified: 2017-08-09 11:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-28 12:34:28 UTC


Attachments (Terms of Use)
File: backtrace (223.96 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: build_ids (9.37 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: cgroup (129 bytes, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: core_backtrace (120.75 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: dso_list (22.89 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: environ (1.61 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: limits (1.29 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: maps (121.63 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: open_fds (3.44 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: proc_pid_status (948 bytes, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: smolt_data (2.92 KB, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details
File: var_log_messages (484 bytes, text/plain)
2013-03-28 00:03 UTC, Jonathan Nicol
no flags Details


Links
System ID Priority Status Summary Last Updated
Document Foundation 71409 None None None 2017-08-09 11:37:37 UTC

Description Jonathan Nicol 2013-03-28 00:03:14 UTC
Description of problem:
copy from Calc sheet, alt-tab, paste into other program, alt-tab back to Calc and it's hung. A few moments later it crashes completely. Calc and Impress were both running at the time.

Version-Release number of selected component:
libreoffice-core-3.6.5.2-6.fc18

Additional info:
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --calc --splash-pipe=6
crash_function: acquire
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.8.3-203.fc18.x86_64
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 acquire at /usr/src/debug/libreoffice-3.6.5.2/solver/unxlngx6.pro/inc/osl/mutex.hxx:67
 #1 ClearableGuard at /usr/src/debug/libreoffice-3.6.5.2/solver/unxlngx6.pro/inc/osl/mutex.hxx:186
 #2 cppu::OInterfaceContainerHelper::disposeAndClear at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:308
 #3 cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:500
 #4 cppu::WeakComponentImplHelperBase::dispose at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/implbase.cxx:276
 #5 disposing at /usr/src/debug/libreoffice-3.6.5.2/comphelper/source/misc/proxyaggregation.cxx:178
 #6 comphelper::OComponentProxyAggregationHelper::disposing at /usr/src/debug/libreoffice-3.6.5.2/comphelper/source/misc/proxyaggregation.cxx:172
 #7 cppu::OInterfaceContainerHelper::disposeAndClear at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:325
 #8 cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:500
 #9 cppu::WeakComponentImplHelperBase::dispose at /usr/src/debug/libreoffice-3.6.5.2/cppuhelper/source/implbase.cxx:276

Comment 1 Jonathan Nicol 2013-03-28 00:03:18 UTC
Created attachment 717358 [details]
File: backtrace

Comment 2 Jonathan Nicol 2013-03-28 00:03:21 UTC
Created attachment 717359 [details]
File: build_ids

Comment 3 Jonathan Nicol 2013-03-28 00:03:23 UTC
Created attachment 717360 [details]
File: cgroup

Comment 4 Jonathan Nicol 2013-03-28 00:03:24 UTC
Created attachment 717361 [details]
File: core_backtrace

Comment 5 Jonathan Nicol 2013-03-28 00:03:33 UTC
Created attachment 717362 [details]
File: dso_list

Comment 6 Jonathan Nicol 2013-03-28 00:03:40 UTC
Created attachment 717363 [details]
File: environ

Comment 7 Jonathan Nicol 2013-03-28 00:03:42 UTC
Created attachment 717364 [details]
File: limits

Comment 8 Jonathan Nicol 2013-03-28 00:03:43 UTC
Created attachment 717365 [details]
File: maps

Comment 9 Jonathan Nicol 2013-03-28 00:03:45 UTC
Created attachment 717366 [details]
File: open_fds

Comment 10 Jonathan Nicol 2013-03-28 00:03:47 UTC
Created attachment 717367 [details]
File: proc_pid_status

Comment 11 Jonathan Nicol 2013-03-28 00:03:49 UTC
Created attachment 717368 [details]
File: smolt_data

Comment 12 Jonathan Nicol 2013-03-28 00:03:51 UTC
Created attachment 717369 [details]
File: var_log_messages

Comment 13 David Tardon 2013-03-28 08:43:46 UTC
Looks like an infinite loop. I doubt we will be able to untangle what the problem is, unless it is reproducible?

Comment 14 Stephan Bergmann 2013-03-28 12:34:28 UTC
An object using that dreaded UNO XAggregation apparently managed to be registered as an XEventListener at itself, but the truncated stack does not give a clue what implementation class that would actually be.

Addressed that with an assert now in upstream <http://cgit.freedesktop.org/libreoffice/core/commit/?id=acca22d64283905048a9441fd30e7179361f2666> "Related rhbz#928568: Detect aggregators listening at themselves," hoping to eventually get it triggered for a debug build there.

Feel free to reopen in case this /is/ reproducible.

Comment 15 Michael Stahl 2017-08-09 11:37:38 UTC
this is still occurring:
https://retrace.fedoraproject.org/faf/reports/1413360/

comment #14 probably misdiagnosed the problem, as cppu::WeakComponentImplHelperBase::dispose protects itself
against re-entrancy, and the "this" pointers in the gdb
trace are all distinct.

the bottom of the trace is:

209 	cppu::WeakComponentImplHelperBase::dispose() 	
210 	comphelper::OComponentProxyAggregationHelper::disposing(com::sun::star::lang::EventObject const&) 	
211 	cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) 	
212 	cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) 	
213 	cppu::WeakComponentImplHelperBase::dispose() 	
214 	comphelper::OComponentProxyAggregationHelper::disposing(com::sun::star::lang::EventObject const&) 	
215 	cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) 	
216 	VCLXWindowImpl::disposing() 	
217 	_ZN3rtl9ReferenceI12OutputDeviceEC4ERKS2_ (inlined) 	
218 	VCLXWindow::dispose() 	
219 	UnoWrapper::WindowDestroyed(vcl::Window*) 	
220 	vcl::Window::dispose() 	
221 	_ZNK12OutputDevice7releaseEv (inlined) 	
222 	ScInputWindow::dispose() 	
223 	_ZNK12OutputDevice7releaseEv (inlined) 	
224 	SfxChildWindow::~SfxChildWindow() 	
225 	ScInputWindowWrapper::~ScInputWindowWrapper() 	
226 	SfxChildWindow::Destroy() 	
227 	SfxWorkWindow::RemoveChildWin_Impl(SfxChildWin_Impl*) 	
228 	SfxWorkWindow::UpdateChildWindows_Impl() 	
229 	SfxWorkWindow::UpdateObjectBars_Impl() 	
230 	SfxFrameWorkWin_Impl::UpdateObjectBars_Impl() 	
231 	SfxDispatcher::Update_Impl(bool) 	
232 	SfxBaseController::ConnectSfxFrame_Impl(SfxBaseController::ConnectSfxFrame) 	
233 	SfxBaseController::attachFrame(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) 	
234 	(anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) 	
235 	framework::LoadEnv::impl_loadContent() 	
236 	framework::LoadEnv::startLoading() 	
237 	framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) 


since it's a ScInputWindow there's a good chance this has the same root cause as TDF bug 71409,
which as it happens was fixed 2 weeks ago.


Note You need to log in before you can comment on or make changes to this bug.