Bug 4025

Summary:	libreoffice segfaults on startup
Product:	Mageia	Reporter:	Dan Fandrich <dan>
Component:	RPM Packages	Assignee:	D Morgan <dmorganec>
Status:	RESOLVED INVALID	QA Contact:
Severity:	major
Priority:	Normal	Keywords:	Triaged, UPSTREAM
Version:	1
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	libreoffice-3.4.4.2-0.3.mga1.src.rpm	CVE:
Status comment:
Attachments:	Crash dump

Description Dan Fandrich 2012-01-05 07:10:03 CET

After installing all updates (including libreoffice 3.4.4.2-0.3.mga1) on MGA1 on an x86 machine, libreoffice crashes immediately after showing the splash screen. Running with libSegFault gives the attached crash dump, which shows a segmentation fault in /usr/lib/libreoffice/basis3.4/program/libsofficeapp.so. This was created with the command:

LD_PRELOAD=/lib/libSegFault.so /usr/lib/libreoffice/program/oosplash.bin --writer

but all command-line options tested (and no option at all) give similar dumps at the same address in libsofficeapp.so.

Comment 1 Dan Fandrich 2012-01-05 07:10:43 CET

Created attachment 1332 [details]
Crash dump

Comment 2 Dan Fandrich 2012-01-05 07:25:20 CET

After some more tracing, I discovered the source of the problem (and likely why it wasn't more widely seen). On this machine exists a root-owned directory /etc/opt/ with 750 permissions, so the user running libreoffice is not able to read its contents. For some reason, libreoffice opens that directory (it's where the proprietary Cisco VPN client stores its configuration) and likely barfs when it can't be read. Changing the permissions to 751 fixes this issue.

Is this due to a Mageia-specific configuration or should I report this upstream?

Comment 3 Manuel Hiebel 2012-01-05 13:36:12 CET

Hi, thanks for reporting this bug.
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)

Keywords: (none) => Triaged
Assignee: bugsquad => dmorganec

Comment 4 Manuel Hiebel 2012-02-21 16:07:20 CET

Oups sorry.

In fact we don't /etc/opt in mageia has default, so indeed it's more an upstream bug. Thanks.

Keywords: (none) => UPSTREAM
Status: NEW => RESOLVED
Resolution: (none) => INVALID