Issue 109682 - Launching OO 3.2 crashes on sigsegv (QSettings::sync: filename is null/empty warnings)
Summary: Launching OO 3.2 crashes on sigsegv (QSettings::sync: filename is null/empty ...
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO320m12
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needhelp
: 109719 (view as issue list)
Depends on:
Reported: 2010-02-28 13:59 UTC by bloody95
Modified: 2014-02-11 21:11 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description bloody95 2010-02-28 13:59:54 UTC
I have just installed on FC12 OpenOffice 3.2 from Version
3.1.1 installed in the same way was working fine.

When running version 3.2, I get the following lines and nothing more than
the splash screen :
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
/opt/openoffice.org3/program/soffice: line 131: 10510 Erreur de segmentation 
"$sd_prog/$sd_binary" "$@"

This happens with my regular account, running a simple window manager and
not the full gnome or kde desktop.

However, the crash does not happen when logged in with a user running under
gnome. It also does not happen if I 'su - <my account>' from this gnomed
user and start then soffice.

Seems like an error code has not been properly checked.

Comment 1 Olaf Felka 2010-03-02 07:02:53 UTC
*** Issue 109719 has been marked as a duplicate of this issue. ***
Comment 2 Olaf Felka 2010-03-02 07:04:06 UTC
@ bloody95: Please give a hint what window manager you use.

*** This issue has been marked as a duplicate of 109719 ***
Comment 3 Olaf Felka 2010-03-02 07:05:50 UTC
Reopening because I've clicked nonsense.
Comment 4 bloody95 2010-03-02 10:38:55 UTC
I am using fvwm95-2 (fvwm95-2.0.43b-1 more specifically).

I kbnow, that's a thing of the past, but running gnome or kde on
some of my machines is no way (not enough memory).

Anyway, this used to work on OO 3.1.1.

Comment 5 bloody95 2010-03-06 12:00:25 UTC
An additional note :

In case fvwm95 looks a little bit too exotic, I have also made the
test with twm (yum install twm), which is the plain old standard window
manager for X11 and got the same issue.

Best regards,
Comment 6 caolanm 2010-03-06 12:38:19 UTC
This is vanilla OOo, not the specific Fedora one, so its not an issue specific
to the Fedora rpms. The warnings look vaguely like they might be from the KDE
integration. Though whether those are related to the final crash is another thing.
Comment 7 bloody95 2010-03-26 02:11:38 UTC
Any news on this ?
Comment 8 philipp.lohmann 2010-03-30 19:33:09 UTC
Installed FC 12. Got twm (there is no fvwm95 package via yum, and I'm not going
to compile one). Seems the twm package comes with a system.twmrc in /etc/X11/twm
but not a link to there from /usr/lib/X11/twm. Anyway the only thing twm manages
to do when it finally finds its own config file is not to be able to open its
preferred font set. Trying to find a suitable one with xlsfonts crashes the X
server, apparently somwhere in freetype.

That was the point where I stopped bothering for the time being.
Comment 9 bloody95 2010-03-30 20:55:55 UTC

Here are my installed fonts (rpm -qa | grep xorg-x11):

I don't remember having configured anything special once these fonts were

Comment 10 bloody95 2010-06-17 22:52:46 UTC
I took some time tonight to look at the differences between a successful
launch and a failing one (using strace).

When launching 3.2 from a gnome session (sucessful launch), the following access
is done :

open("/opt/", O_RDONLY) = 3

When launching from the legacy window manager (failure), the following access is
done :

open("/opt/", O_RDONLY) = 3

So, it seems that OO is considering that it runs in a KDE environment, which
it does not.

From then, the loaded libraries are completely different.

Maybe should I reinstall 3.1.1 and check where the paths begin to diverge.