Bug 828516

Summary: [abrt] libreoffice-core- _XIOError -> FontSubstConfiguration dtor: killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Matthieu Pupat <redhat_bugzilla>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED WONTFIX 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:b17c2195a61788e67b9c2a52c74fb1a29ffe089c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-05 07:06:54 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
File: build_ids
File: maps
File: backtrace none

Description Matthieu Pupat 2012-06-04 16:13:53 EDT
libreport version: 2.0.10
abrt_version:   2.0.10
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin -writer --splash-pipe=6
crash_function: __GI_exit
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.3.7-1.fc17.x86_64
pid:            3017
pwd:            /home/matthieu
time:           Sun 03 Jun 2012 09:37:10 PM CEST
uid:            1000

backtrace:      Text file, 40156 bytes
build_ids:      Text file, 8282 bytes
maps:           Text file, 96602 bytes


:'LESSOPEN=||/usr/bin/lesspipe.sh %s'

:Limit                     Soft Limit           Hard Limit           Units     
:Max cpu time              unlimited            unlimited            seconds   
:Max file size             unlimited            unlimited            bytes     
:Max data size             unlimited            unlimited            bytes     
:Max stack size            8388608              unlimited            bytes     
:Max core file size        0                    unlimited            bytes     
:Max resident set          unlimited            unlimited            bytes     
:Max processes             1024                 59184                processes 
:Max open files            4096                 4096                 files     
:Max locked memory         65536                65536                bytes     
:Max address space         unlimited            unlimited            bytes     
:Max file locks            unlimited            unlimited            locks     
:Max pending signals       59184                59184                signals   
:Max msgqueue size         819200               819200               bytes     
:Max nice priority         0                    0                    
:Max realtime priority     0                    0                    
:Max realtime timeout      unlimited            unlimited            us        

:pos:	0
:flags:	0100000
:pos:	443334
:flags:	0102002
:pos:	443334
:flags:	0102002
:pos:	0
:flags:	02004002
:pos:	0
:flags:	02004002
:pos:	0
:flags:	00
:pos:	0
:flags:	01
:pos:	0
:flags:	02000002
Comment 1 Matthieu Pupat 2012-06-04 16:13:58 EDT
Created attachment 589272 [details]
File: build_ids
Comment 2 Matthieu Pupat 2012-06-04 16:14:01 EDT
Created attachment 589273 [details]
File: maps
Comment 3 Matthieu Pupat 2012-06-04 16:14:03 EDT
Created attachment 589274 [details]
File: backtrace
Comment 4 Caolan McNamara 2012-06-05 07:06:54 EDT
An unexpected XIOError leading to FontSubstConfiguration shutdown and a crash during that. Odd thing is that the dtors seem to be called from thread 3 and not thread 1 as I'd expect. Don't really know what that is.

Anyway, we can't survive an XIOError (x server connection gone away) so while it'd be nicer to have a cleaner shutdown on disconnect its not a serious problem in the absence of an easy-fix.
Comment 5 Stephan Bergmann 2012-06-05 07:38:13 EDT
(In reply to comment #4)
> Odd thing is that the dtors seem to be called from thread
> 3 and not thread 1 as I'd expect. Don't really know what that is.

Looks like both the main thread (reported as thread #3) and the SelectionManager thread (reported as thread #1) raced for _XIOError -> ... -> __run_exit_handlers, and the main thread happened to win.