[SRU] soffice.bin crashed with SIGSEGV in Application::GetSolarMutex()

Bug #1418551 reported by Josef Hopfgartner on 2015-02-05
72
This bug affects 11 people
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Medium
libreoffice (Ubuntu)
Medium
Unassigned
Vivid
Medium
Unassigned

Bug Description

[Impact]

 * crash on close of document

 * possible loss of data (from other unsaved documents still open)

 * top1 crasher for LibreOffice on errors.ubuntu.com

 * regression versus prior major releases of LibreOffice

[Test Case]

 * not easily/reliably reproducable sadly

[Regression Potential]

 * low: minimal patch, not a core code area (only affects scenarios using StarBasic, not document model or e.g. layout), tested upstream and in PPA

[Other Info]

closed libreoffice calc
a java update has been running while soffice.bin was in action...

ProblemType: Crash
DistroRelease: Ubuntu 15.04
Package: libreoffice-core 1:4.4.0~rc2-0ubuntu3
ProcVersionSignature: Ubuntu 3.18.0-11.12-generic 3.18.3
Uname: Linux 3.18.0-11-generic x86_64
ApportVersion: 2.15.1-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Feb 5 14:20:32 2015
ExecutablePath: /usr/lib/libreoffice/program/soffice.bin
ProcCmdline: /usr/lib/libreoffice/program/soffice.bin --calc --splash-pipe=6
SegvAnalysis:
 Segfault happened at: 0x7fe8106f7e7a <_ZN11Application13GetSolarMutexEv+10>: mov 0x8(%rax),%rdi
 PC (0x7fe8106f7e7a) ok
 source "0x8(%rax)" (0x00000008) not located in a known VMA region (needed readable region)!
 destination "%rdi" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: libreoffice
StacktraceTop:
 Application::GetSolarMutex() () from /usr/lib/libreoffice/program/libvcllo.so
 ?? () from /usr/lib/libreoffice/program/libsblo.so
 ?? () from /usr/lib/libreoffice/program/libsblo.so
 ?? () from /usr/lib/libreoffice/program/libsblo.so
 __run_exit_handlers (status=0, listp=0x7fe8156096c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
Title: soffice.bin crashed with SIGSEGV in Application::GetSolarMutex()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: admin bacula dialout fuse libvirtd pcscd plugdev sudo

StacktraceTop:
 Application::GetSolarMutex () at /build/buildd/libreoffice-4.4.0~rc2/vcl/source/app/svapp.cxx:409
 SolarMutexGuard (this=<synthetic pointer>) at /build/buildd/libreoffice-4.4.0~rc2/include/vcl/svapp.hxx:1567
 DocBasicItem::~DocBasicItem (this=0x7fe7d83d1610, __in_chrg=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/basic/source/classes/sb.cxx:112
 DocBasicItem::~DocBasicItem (this=0x7fe7d83d1610, __in_chrg=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/basic/source/classes/sb.cxx:116
 release (this=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/include/cppuhelper/implbase1.hxx:109

Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu):
status: New → Confirmed

This seems to be a crash on document close, which is good to know. Is there a good example document/reproduction scenario?

information type: Private → Public
Changed in libreoffice (Ubuntu):
status: Confirmed → Incomplete

regression vs. 4.3: crash on close from BASIC -- stacktrace downstream at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1418551

Download full text (4.3 KiB)

StractraceTop:
#0 0x00007fe8106f7e7a in Application::GetSolarMutex () at /build/buildd/libreoffice-4.4.0~rc2/vcl/source/app/svapp.cxx:409
No locals.
#1 0x00007fe812acd81c in SolarMutexGuard (this=<synthetic pointer>) at /build/buildd/libreoffice-4.4.0~rc2/include/vcl/svapp.hxx:1567
No locals.
#2 DocBasicItem::~DocBasicItem (this=0x7fe7d83d1610, __in_chrg=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/basic/source/classes/sb.cxx:112
No locals.
#3 0x00007fe812acd949 in DocBasicItem::~DocBasicItem (this=0x7fe7d83d1610, __in_chrg=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/basic/source/classes/sb.cxx:116
No locals.
#4 0x00007fe812ad1835 in release (this=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/include/cppuhelper/implbase1.hxx:109
No locals.
#5 ~Reference (this=0x7fe7d83d4c78, __in_chrg=<optimized out>) at /build/buildd/libreoffice-4.4.0~rc2/include/rtl/ref.hxx:75
No locals.
#6 ~pair (this=0x7fe7d83d4c70, __in_chrg=<optimized out>) at /usr/include/c++/4.9/bits/stl_pair.h:96
No locals.
#7 destroy<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > (this=<optimized out>, __p=0x7fe7d83d4c70) at /usr/include/c++/4.9/ext/new_allocator.h:124
No locals.
#8 destroy<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > (a=..., p=0x7fe7d83d4c70) at /usr/include/boost/unordered/detail/allocate.hpp:591
No locals.
#9 destroy_value_impl<std::allocator<boost::unordered::detail::ptr_node<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > >, std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > (alloc=..., x=0x7fe7d83d4c70) at /usr/include/boost/unordered/detail/allocate.hpp:788
No locals.
#10 delete_node (this=<optimized out>, prev=0x7fe7d81ade10) at /usr/include/boost/unordered/detail/table.hpp:519
        n = 0x7fe7d83d4c70
#11 delete_nodes (end=0x0, prev=0x7fe7d81ade10, this=0x7fe812e09020 <rtl::Static<boost::unordered::unordered_map<StarBASIC const*, rtl::Reference<DocBasicItem>, boost::hash<StarBASIC const*>, std::equal_to<StarBASIC const*>, std::allocator<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > >, (anonymous namespace)::GaDocBasicItems>::get()::instance>) at /usr/include/boost/unordered/detail/table.hpp:534
        count = <optimized out>
#12 delete_buckets (this=0x7fe812e09020 <rtl::Static<boost::unordered::unordered_map<StarBASIC const*, rtl::Reference<DocBasicItem>, boost::hash<StarBASIC const*>, std::equal_to<StarBASIC const*>, std::allocator<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > >, (anonymous namespace)::GaDocBasicItems>::get()::instance>) at /usr/include/boost/unordered/detail/table.hpp:544
No locals.
#13 ~table (this=0x7fe812e09020 <rtl::Static<boost::unordered::unordered_map<StarBASIC const*, rtl::Reference<DocBasicItem>, boost::hash<StarBASIC const*>, std::equal_to<StarBASIC const*>, std::allocator<std::pair<StarBASIC const* const, rtl::Reference<DocBasicItem> > > >, (anonymous namespace)::GaDocBasicItems>::get()::instance>, __in_chrg=<optimized out>) at /usr/include/boost/unordered/detail/table.hpp:511
No locals.
#14 ~table_impl (this=0x7fe812e09020 <rtl::Static<boost::unordered::unordered_m...

Read more...

This seems to be caused by a1fad26e045ff1fec0c63243e3516ef2da7f390d "fdo#84935: basic: DocBasicItem is a UNO service, lock SolarMutex in dtor"

The GaDocBasicItems is a rtl::Static<> and seems to thus live longer than even the SolarMutex -- as the change above is trying to get a guard for the mutex in dtor, that map has to be cleared before the SolarMutex is gone.

Also: Did any of the reporters have extensions installed? Did any of the reporters have NO extension installed? If the former, a list of extensions would be interesting.

A likely commit has been identified - marking as bisected

Harm van Bakel (hvbakel) wrote :

In my case at least some of these crashes seem to be related to the loss of the gvfsd-sftp mount point where the document was loaded from.

Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=be88e305eeac88e51f83efc004d4b60b87f1e757

tdf#90969: basic: add horrible hack to avoid crash due to ...

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

added a work-around for the BASIC global variable madness on master

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Fix Released

Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=098817edf3c5d16ab476fbb996807e7654597990&h=libreoffice-4-4

tdf#90969: basic: add horrible hack to avoid crash due to ...

It will be available in 4.4.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

description: updated
summary: - soffice.bin crashed with SIGSEGV in Application::GetSolarMutex()
+ [SRU] soffice.bin crashed with SIGSEGV in Application::GetSolarMutex()
description: updated
Changed in libreoffice (Ubuntu):
status: Incomplete → Fix Committed
Changed in libreoffice (Ubuntu):
milestone: none → vivid-updates
C de-Avillez (hggdh2) on 2015-06-03
Changed in libreoffice (Ubuntu Vivid):
milestone: none → vivid-updates

*** Bug 91214 has been marked as a duplicate of this bug. ***

*** Bug 92012 has been marked as a duplicate of this bug. ***

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu Vivid):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libreoffice - 1:4.4.4~rc3-0ubuntu1

---------------
libreoffice (1:4.4.4~rc3-0ubuntu1) wily; urgency=medium

  * new upstream rc, includes hack to prevent crash on exit (LP: #1418551)
  * Fix mailmerge without libreoffice-base scenario

 -- Bjoern Michaelsen <email address hidden> Mon, 06 Jul 2015 17:24:44 +0200

Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released
Mathew Hodson (mhodson) on 2015-11-12
Changed in libreoffice (Ubuntu):
milestone: vivid-updates → none
Changed in libreoffice (Ubuntu Vivid):
importance: Undecided → Medium

Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]

vivid is EOL

Changed in libreoffice (Ubuntu Vivid):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.