Bug 773557

Summary: [abrt] libreoffice-core- stoc_bootstrap::smgr_getImplementationName (SIGSEGV), [ntfs ?]
Product: [Fedora] Fedora Reporter: Gawain Lynch <gawain.lynch>
Component: libreofficeAssignee: Stephan Bergmann <sbergman>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: caolanm, dtardon, erack, ltinkl, mstahl, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:f3f20520f130f29b35f8ee790737bd98db466cdd
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-29 03:14:38 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
File: dso_list
File: maps
File: backtrace none

Description Gawain Lynch 2012-01-12 04:17:01 EST
libreport version: 2.0.8
abrt_version:   2.0.7
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --writer file:///tmp/TaylorEB_Abstract.odt --splash-pipe=7
comment:        Problem occurs on launch.  Nothing outputted to console on lauching via command line either.
crash_function: stoc_bootstrap::smgr_getImplementationName
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.1.7-1.fc16.x86_64
pid:            10064
pwd:            /media/Win7_NTFS/Users/Gawain
reason:         Process /usr/lib64/libreoffice/program/soffice.bin was killed by signal 11 (SIGSEGV)
time:           Thu 12 Jan 2012 03:21:37 PM EST
uid:            1000
username:       gawain

backtrace:      Text file, 20579 bytes
dso_list:       Text file, 5763 bytes
maps:           Text file, 21491 bytes

:'LESSOPEN=||/usr/bin/lesspipe.sh %s'
:'MOZ_CRASHREPORTER_DATA_DIRECTORY=/home/gawain/.mozilla/firefox/Crash Reports'

:Jan 12 15:21:37 legolas kernel: [17401.878402] soffice.bin[10064]: segfault at 7fbc9baa6090 ip 00007fbc9bab5310 sp 00007fffd79e8fb8 error 7 in bootstrap.uno.so[7fbc9ba7c000+b8000]
:Jan 12 15:21:37 legolas abrt[10066]: Saved core dump of pid 10064 (/usr/lib64/libreoffice/program/soffice.bin) to /var/spool/abrt/ccpp-2012-01-12-15:21:37-10064 (11907072 bytes)
Comment 1 Gawain Lynch 2012-01-12 04:17:06 EST
Created attachment 552350 [details]
File: dso_list
Comment 2 Gawain Lynch 2012-01-12 04:17:10 EST
Created attachment 552351 [details]
File: maps
Comment 3 Gawain Lynch 2012-01-12 04:17:12 EST
Created attachment 552352 [details]
File: backtrace
Comment 4 Caolan McNamara 2012-01-12 06:06:08 EST
This crashes for you on every launch ?, or just with a specific file. Sort of looks to me like the libs themselves are busted and there's something wrong with the install.

yum erase libreoffice-ure 
yum install libreoffice
might help there to remove all the libreoffice stuff and install the default libreoffice packages again
Comment 5 Caolan McNamara 2012-02-28 12:09:13 EST
hmm, iniDir = "file:///media/Win7_NTFS/Users/Gawain", that's a little unusual. Perhaps that's the trigger, having a ntfs mounted home dir.

What way is that dir mounted ?, i.e. output of
mount | grep Gawain

caolanm->sbergman: any thoughts about the above backtrace given the possibility of a iniDir on a foreign filesystem ?
Comment 6 Gawain Lynch 2012-02-28 20:37:49 EST
Oh my, sorry I forgot about this.  I'm in Haiti and overloaded with work.

* The home directory is on an NTFS partition
* Originally /home/gawain was a symlink to the NTFS mount (/home was ext4)
* /home/gawain is now a bind mount of /media/Win7_NTFS/Users/Gawain
* The crashes would start consistently happening after a reinstall and 2 or 3 restarts of the OS
* `rpm -V` reported no problems
* libreoffice has been stable now for a couple of weeks, probably due to one of the updates

It is worth noting that I am using an ASUS ZenBook and there were multiple "wierdnesses" that disappeared circa kernel-3.2.

However, I am no longer seeing the problem and if you require nothing more in the way of information from me I am happy to close this BZ.
Comment 7 Stephan Bergmann 2012-02-29 03:14:38 EST
"Wierdnesses" probably describes what one sees here best.  From the attached bt, it would look like SEGVing on push %rbx upon entry to stoc_bootstrap::smgr_getImplementationName, i.e., the stack pointer %rsp pointing outside allocated memory.  But there is no reason why cppu::component_getFactoryHelper should call with a broken %rsp (and for frame #1 the stack is apparently still OK, as gdb could otherwise not display its locals).  And the failing code path seems completely unrelated to whether iniDir points to an NTFS mount.  So closing this.