RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 908674 - Any LibreOffice program doesn't start
Summary: Any LibreOffice program doesn't start
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreoffice
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephan Bergmann
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-07 10:16 UTC by Matěj Cepl
Modified: 2014-06-13 12:38 UTC (History)
4 users (show)

Fixed In Version: libreoffice-4.0.0.3-5.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:38:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
backtrace (7.92 KB, text/plain)
2013-02-12 15:01 UTC, Matěj Cepl 		no flags Details
valgrind report (42.62 KB, text/plain)
2013-02-13 11:11 UTC, Matěj Cepl 		no flags Details
valgrind report with VALGRIND="memcheck -v" (91.28 KB, text/plain)
2013-02-13 11:19 UTC, Matěj Cepl 		no flags Details
View All

Description Matěj Cepl 2013-02-07 10:16:32 UTC 
Description of problem:
(please correct my double negatives if they are wrong ;))
I have installed LO from https://brewweb.devel.redhat.com/buildinfo?buildID=254633 and when I start any program from LO, I get error message saying

The program cannot be started.
The service manager is not available.
("file:///usr/lib64/libreoffice/ure/lib/bootstrap.uno.so: cannot get factory of demanded implementation: ")
Start setup application to repair the installation from CD, or the folder containing the installation packages.

Version-Release number of selected component (if applicable):
libreoffice-4.0.0.3-2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Just as I said, install from the Brew build
2.run oowriter (for example)
3.
  
Actual results:
splashscreen shows up, runs for a moment, and ends with an error box saying above mentioned.
The proper window for the application hasn't been created yet.

Expected results:
Proper LO Writer window showing up and plenty of ponnies!

Additional info:
Comment 2 Matěj Cepl 2013-02-12 15:01:37 UTC 
Created attachment 696536 [details]
backtrace

see, I have even this nice backtrace!
Comment 3 Caolan McNamara 2013-02-12 23:04:55 UTC 
doesn't "speak" to me yet.
Comment 4 Stephan Bergmann 2013-02-13 09:07:46 UTC 
Does "VALGRIND=memcheck /usr/bin/soffice" show anything suspicious?
Comment 5 Matěj Cepl 2013-02-13 11:11:44 UTC 
Created attachment 696764 [details]
valgrind report

Interesting! With

VALGRIND=memcheck /usr/bin/soffice

there was no crash and LO actually started.
Comment 6 Matěj Cepl 2013-02-13 11:19:47 UTC 
Created attachment 696777 [details]
valgrind report with VALGRIND="memcheck -v"

With VALGRIND="memcheck -v" we are back in the core dump territory.

matej@wycliff: ~$ gdb --core=vgcore.10920 /usr/lib64/libreoffice/program/soffice.bin 
GNU gdb (GDB) Red Hat Enterprise Linux (7.5.1-34.el7)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib64/libreoffice/program/soffice.bin...Reading symbols from /usr/lib/debug/usr/lib64/libreoffice/program/soffice.bin.debug...done.
done.
[New LWP 10944]
[New LWP 10943]
[New LWP 10931]
[New LWP 10920]
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error

warning: File "/usr/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
	add-auto-load-safe-path /usr/lib64/libthread_db-1.0.so
line to your configuration file "/home/matej/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/matej/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info

warning: Skipping deprecated .gdb_index section in /usr/lib/debug/lib64/libkeyutils.so.1.4.debug.
Do "set use-deprecated-index-sections on" before the file is read
to use the section anyway.
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error

warning: File "/usr/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000005c1712d in accept () at ../sysdeps/unix/syscall-template.S:81
81	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install krb5-libs-1.11-0.el7.beta1.0.x86_64 liblangtag-0.4.0-2.el7.x86_64
(gdb) t a a bt

Thread 4 (LWP 10920):
#0  0x00000000271372b7 in lock (this=<optimized out>)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/inc/threadhelp/writeguard.hxx:121
#1  framework::WriteGuard::lock (this=0x7feffe460)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/inc/threadhelp/writeguard.hxx:106
#2  0x00000000271b2e3e in WriteGuard (rLock=..., this=0x7feffe460)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/inc/threadhelp/writeguard.hxx:76
#3  framework::PathSettings::fa_getCfgNew (this=this@entry=0x2518e7c0)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/source/services/pathsettings.cxx:1142
#4  0x00000000271b53a6 in framework::PathSettings::impl_readAll (this=0x2518e7c0)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/source/services/pathsettings.cxx:206
#5  0x00000000271af271 in framework::PathSettings::impl_createInstance (
    xServiceManager=...)
    at /usr/src/debug/libreoffice-4.0.0.3/framework/source/services/pathsettings.cxx:104
#6  0x000000000692daea in cppu::OSingleFactoryHelper::createInstanceEveryTime (
    this=0x24a5e3f0, xContext=...)
    at /usr/src/debug/libreoffice-4.0.0.3/cppuhelper/source/factory.cxx:173
#7  0x000000000692f1b8 in createInstanceWithContext (xContext=..., this=
    0x24a5e3f0)
    at /usr/src/debug/libreoffice-4.0.0.3/cppuhelper/source/factory.cxx:205
#8  cppu::OFactoryComponentHelper::createInstanceWithContext (this=0x24a5e388, 
    xContext=...)
    at /usr/src/debug/libreoffice-4.0.0.3/cppuhelper/source/factory.cxx:471
#9  0x0000000006913984 in (anonymous namespace)::ServiceManager::createInstanceWithContext (this=0x40b8308, aServiceSpecifier=..., Context=...)
    at /usr/src/debug/libreoffice-4.0.0.3/cppuhelper/source/defaultbootstrap.cxx:989
#10 0x000000000690bdd4 in (anonymous namespace)::ServiceManager::createInstance (
    this=<optimized out>, aServiceSpecifier=...)
    at /usr/src/debug/libreoffice-4.0.0.3/cppuhelper/source/defaultbootstrap.cxx:939
#11 0x0000000008d4e6ac in SvtPathOptions_Impl::SvtPathOptions_Impl (this=
    0x2570fa10)
    at /usr/src/debug/libreoffice-4.0.0.3/unotools/source/config/pathoptions.cxx:424
#12 0x0000000008d51715 in SvtPathOptions::SvtPathOptions (this=0x7feffebf0)
    at /usr/src/debug/libreoffice-4.0.0.3/unotools/source/config/pathoptions.cxx:495
#13 0x00000000050bcc58 in desktop::Desktop::CreateTemporaryDirectory (
    this=this@entry=0x7fefff2d0)
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/appinit.cxx:266
#14 0x00000000050be004 in desktop::Desktop::RegisterServices (this=0x7fefff2d0, 
    context=...)
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/appinit.cxx:155
#15 0x00000000050ab613 in desktop::Desktop::Main (this=0x7fefff2d0)
---Type <return> to continue, or q <return> to quit---
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/app.cxx:1409
#16 0x0000000009105db1 in ImplSVMain ()
    at /usr/src/debug/libreoffice-4.0.0.3/vcl/source/app/svmain.cxx:162
#17 0x0000000009106105 in SVMain ()
    at /usr/src/debug/libreoffice-4.0.0.3/vcl/source/app/svmain.cxx:199
#18 0x00000000050de525 in soffice_main ()
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/sofficemain.cxx:74
#19 0x000000000040073b in sal_main ()
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/main.c:48
#20 main (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/main.c:47

Thread 3 (LWP 10931):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:217
#1  0x0000000004e4f929 in rtl_cache_wsupdate_wait (seconds=10)
    at /usr/src/debug/libreoffice-4.0.0.3/sal/rtl/source/alloc_cache.cxx:1388
#2  rtl_cache_wsupdate_all (arg=<optimized out>)
    at /usr/src/debug/libreoffice-4.0.0.3/sal/rtl/source/alloc_cache.cxx:1528
#3  0x0000000005ee3d15 in start_thread (arg=0x151c2700) at pthread_create.c:308
#4  0x0000000005c1646d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114

Thread 2 (LWP 10943):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:217
#1  0x0000000004e69890 in osl_waitCondition (Condition=0x256f86e0, pTimeout=
    0x263bdd60) at /usr/src/debug/libreoffice-4.0.0.3/sal/osl/unx/conditn.cxx:255
#2  0x00000000247cc074 in wait (pTimeout=0x263bdd60, this=<optimized out>)
    at /usr/src/debug/libreoffice-4.0.0.3/solver/unxlngx6.pro/inc/osl/conditn.hxx:75
#3  configmgr::Components::WriteThread::execute (this=0x256f8640)
    at /usr/src/debug/libreoffice-4.0.0.3/configmgr/source/components.cxx:178
#4  0x0000000006fe5cb6 in salhelper::Thread::run (this=0x256f8640)
    at /usr/src/debug/libreoffice-4.0.0.3/salhelper/source/thread.cxx:60
#5  0x0000000006fe5f2a in osl::threadFunc (param=0x256f8650)
    at /usr/src/debug/libreoffice-4.0.0.3/solver/unxlngx6.pro/inc/osl/thread.hxx:187
#6  0x0000000004e49527 in osl_thread_start_Impl (pData=0x256f8780)
    at /usr/src/debug/libreoffice-4.0.0.3/sal/osl/unx/thread.c:252
#7  0x0000000005ee3d15 in start_thread (arg=0x263be700) at pthread_create.c:308
#8  0x0000000005c1646d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114

Thread 1 (LWP 10944):
#0  0x0000000005c1712d in accept () at ../sysdeps/unix/syscall-template.S:81
#1  0x0000000004e43b80 in osl_acceptPipe (pPipe=0x256f9440)
    at /usr/src/debug/libreoffice-4.0.0.3/sal/osl/unx/pipe.c:458
#2  0x00000000050da02a in accept (Connection=..., this=0x256f8b48)
    at /usr/src/debug/libreoffice-4.0.0.3/solver/unxlngx6.pro/inc/osl/pipe.hxx:132
#3  desktop::OfficeIPCThread::execute (this=<optimized out>)
---Type <return> to continue, or q <return> to quit---
    at /usr/src/debug/libreoffice-4.0.0.3/desktop/source/app/officeipcthread.cxx:651
#4  0x0000000006fe5cb6 in salhelper::Thread::run (this=0x256f8b20)
    at /usr/src/debug/libreoffice-4.0.0.3/salhelper/source/thread.cxx:60
#5  0x0000000006fe5f2a in osl::threadFunc (param=0x256f8b30)
    at /usr/src/debug/libreoffice-4.0.0.3/solver/unxlngx6.pro/inc/osl/thread.hxx:187
#6  0x0000000004e49527 in osl_thread_start_Impl (pData=0x256fa490)
    at /usr/src/debug/libreoffice-4.0.0.3/sal/osl/unx/thread.c:252
#7  0x0000000005ee3d15 in start_thread (arg=0x26bbf700) at pthread_create.c:308
#8  0x0000000005c1646d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114
(gdb)
Comment 7 Stephan Bergmann 2013-02-13 15:55:46 UTC 
So I can reproduce the symptoms with a local upstream libreoffice-4-0-0 build on Fedora 18 x86_64 when I mimic the configure switches and CFLAGS/CXXFLAGS/LDFLAGS settings from <http://download.devel.redhat.com/brewroot/packages/libreoffice/4.0.0.3/2.el7/data/logs/x86_64/build.log>.
Comment 8 Stephan Bergmann 2013-02-18 09:13:05 UTC 
This turned out to be a problem that only appears with sufficiently recent Boost (at least Boost 1.50 and building LibreOffice --with-system-boost, not when building against the Boost 1.44 sources included in LibreOffice), and only with LibreOffice 4 (as the relevant code was not there in older versions).  It has been fixed in upstream LibreOffice (<http://cgit.freedesktop.org/libreoffice/core/commit/?id=c91d353872b7d4e1a39192bff1444b46cab6e5eb> "rhbz#908674: Adapt rtl::Allocator::construct to C++11") and in Fedora 19 libreoffice-4.0.0.3-5.fc19.
Comment 9 Stephan Bergmann 2013-02-22 09:25:24 UTC 
[should have been set to MODIFIED instead of CLOSED CURRENTRELEASE]
Comment 10 Vladimir Benes 2014-02-18 13:51:46 UTC 
libreoffice programs start correctly
Comment 11 Ludek Smid 2014-06-13 12:38:52 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.