Bug 78477 - segfault on startup, but only with some fonts installed
Summary: segfault on startup, but only with some fonts installed
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: highest critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.4.0 target:4.3.0.0.beta2 tar...
Keywords: bibisected, regression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-05-09 09:09 UTC by Marcello Magnifico
Modified: 2015-12-17 08:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
TrueType font file (36.54 KB, application/font-sfnt)
2014-05-09 09:09 UTC, Marcello Magnifico
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcello Magnifico 2014-05-09 09:09:58 UTC
Created attachment 98738 [details]
TrueType font file

Greetings,
    I'm using LibreOffice 4.1.4.2 from the backports repository of Debian Linux 7, with some thousand files in my ~/.font directory, which keeps growing up as I'm collecting fonts since a long time ago. It was possible to isolate, via strace, a segmentation fault in libvcllo.so, which prevented LibreOffice from starting at all. Removing from ~/.fonts just a couple of fonts (one is attached here; they seem to belong to the same family) allowed LibreOffice to start flawlessly again. Opening the fonts with gnome-font-viewer allowed to see they're made only of numeric digits and some symbol; which is not expected to cause a segmentation fault anyway. It must be something in the file structure.

    I'm unsure about the weakness creating this problem, apparently due to some poor handling of bad/unexpected data. If it's located in lower level components used by libvcllo.so, then I shall move the problem to the Debian maintaners for sure.

    If, however, it is due to LibreOffice itself, solving this problem might even close unconfirmed/unreproduceable situations sharing the same cause; which seems an opportunity too important to ignore. Is anyone capable/willing to test this with other versions of LibreOffice and/or Linux? The test isn't supposed to corrupt your system, if the behavior is the same I experienced then it will be sufficient to remove the offending font to get LibreOffice running again. Thanks.


    best regards
    Marcello
Comment 1 retired 2014-05-09 15:11:56 UTC
Is this bug still valid / reproducible with the latest LO release?  Currently 4.2.4: http://www.libreoffice.org/download/libreoffice-fresh/

Please also try resetting your user profile and let us know if that helps: https://wiki.documentfoundation.org/UserProfile

Should this be still reproducible for you with the latest LO release please set this bug back to UNCONFIRMED. Should this issue be solved set it to WORKSFORME.

Setting to NEEDINFO until more detail is provided.
Comment 2 Marcello Magnifico 2014-05-09 19:20:58 UTC
(In reply to comment #1)
> Is this bug still valid / reproducible with the latest LO release? 
> Currently 4.2.4: http://www.libreoffice.org/download/libreoffice-fresh/

Yes. That took more than expected, sorry for the delay.

Debian 7 apparently does not allow to remove Libreoffice packages coming from their repository without taking down GNOME3 itself. I had no time to test a mixed setup on that same workstation.

The tests continued within a lower priority x86_64 machine, a PearOS6.1 (Ubuntu 12.04 derivative) which was born with an old LO3 so seldom used I couldn't tell when the last time was. A freshly downloaded LO4.2.4.2 (thanks for the direct link) was put in place even before thinking to test LO3 itself. The problem turned to be reproduceable with no differences at all.

Analysis details follow.

The splash screen with the progress bar will just disappear while the progress bar is still incomplete and nothing more will happen. The segfault is silent, so difficult to detect that one could doubt that an error of such magnitude actually took place. If you launch LO from a terminal window, you will get nothing on stdout nor stderr. Check the dmesg command for the latest system events, and it's there.

The output from 'strace -f loffice' will report the open system call for the offending font (the one provided or, supposedly, any other one causing the same effect) just a few lines before the segfault. That was the only hint suggesting to remove the last font accessed by the application.


> Please also try resetting your user profile and let us know if that helps:
> https://wiki.documentfoundation.org/UserProfile

That was not needed, as the old and new version of LO on the test system are different by major release. Removing the two offending fonts (which were already on place, as I periodically rsynced some data from a network share) was sufficient.


> Should this be still reproducible for you with the latest LO release please
> set this bug back to UNCONFIRMED.

Now. Thanks for your attention.
Comment 3 Joel Madero 2014-06-04 04:04:44 UTC
Really strange one - at first I thought it was a bug with the font but it's a regression. 

Ubuntu 14.04
LibreOffice 4.2.4.2 release
Critical - crasher but unlikely to affect many users (very specific to this font or some extra fonts, blockers are only for crashers that are affecting a majority of our users)
Highest - regression

Most Annoying Bug - think this qualifies

Reproducible Steps:
Download the font and place it in ~/.font
Reconfigure your font cache (Ubuntu this is "sudo dpkg-reconfigure fontconfig")

Try running LibreOffice and see the crash every time.

 1c3f60eb0c69e2de954da5c7fdc8f3c3eda04a3b is the first bad commit
commit 1c3f60eb0c69e2de954da5c7fdc8f3c3eda04a3b
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Oct 16 03:01:27 2013 +0000

    source-hash-8cc6699ade4e1e1b7b00d7034b12c3aec2ed50e9
    
    commit 8cc6699ade4e1e1b7b00d7034b12c3aec2ed50e9
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Sat Jan 12 21:36:45 2013 +0100
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Mon Jan 14 08:28:29 2013 +0100
    
        -Werror,-Wtautological-constant-out-of-range-compare
    
        ...comparing enum eOption with -1
    
        Change-Id: I927b71d1e9988a39ffc1be585ab4bdecfd16b226

:100644 100644 7f1a86df8b948ff723ca82a887d466cae6d7cb8e 94706a873e7a411d7a96baab006e561345286a29 M	autogen.log
:100644 100644 fc98faf560d47ba9c481ff8cc08d376f933cf9f5 1a44913a0415b4611a5400a82e7c42701bc9391f M	ccache.log
:100644 100644 5a35512fa26ffd691c1d34b9629eb928b9eb2152 bd38fe1e9da5aecb7725279e86229418668769a1 M	commitmsg
:100644 100644 352e470e5838a9bcd057849455f0f2510509214f 85a49c2f959ada586ba0d87b6035caac1480cb4a M	dev-install.log
:100644 100644 fbdd784b6ee0bff4b22b2fd5d25d3233f63c0f90 7cb096984bebd622b3d16c82bda011a4c8bf067e M	make.log
:040000 040000 2dee41feeffa94fc2a13caf9eaabefa1edabcc68 f278976b8e764385e3a8bdcd2741c6a7d4089ef7 M	opt


# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# good: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect good d65a58c31c8da044ef66ae4517fa2fe74cec0019
# good: [00f5ea8ff23485332a8009f8017ae95cd5f83fa4] source-hash-4ef5ed9d21de767ce1b4c70d73cf15994b38dcdb
git bisect good 00f5ea8ff23485332a8009f8017ae95cd5f83fa4
# good: [b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b] source-hash-ec376c2934e77fd1b56da892cfe2c1393f4c8156
git bisect good b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b
# good: [2432222b43bc847d69313b670fb66f5481c6510e] source-hash-194ba3a2cacbb5438dfcb8fb35167055e01ca251
git bisect good 2432222b43bc847d69313b670fb66f5481c6510e
# bad: [31bac4fcc40da1e460b132be36dfa002e52919d0] source-hash-d55155cad0926f61b5745260196b93e95471d06a
git bisect bad 31bac4fcc40da1e460b132be36dfa002e52919d0
# bad: [1c3f60eb0c69e2de954da5c7fdc8f3c3eda04a3b] source-hash-8cc6699ade4e1e1b7b00d7034b12c3aec2ed50e9
git bisect bad 1c3f60eb0c69e2de954da5c7fdc8f3c3eda04a3b
# first bad commit: [1c3f60eb0c69e2de954da5c7fdc8f3c3eda04a3b] source-hash-8cc6699ade4e1e1b7b00d7034b12c3aec2ed50e9
Comment 4 ⁨خالد حسني⁩ 2014-06-04 12:02:21 UTC
The font is seriously broken, no font tool that I have is able to process it (either crashes or rejects it), namely it seems to have an invalide ‘name’ table. LibreOffice seems to be crashing in psp::PrintFontManager::analyzeTrueTypeFamilyName() (quite expected), but I don’t have a master build to farther debug it.
Comment 5 Commit Notification 2014-06-04 15:39:51 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: fdo#78477 ensure offset + sizeof(value) is in bounds



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.
Comment 6 Commit Notification 2014-06-04 15:57:01 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=891e0f76350890a4dd4331820bde8c118ac06ab0&h=libreoffice-4-3

Resolves: fdo#78477 ensure offset + sizeof(value) is in bounds


It will be available in LibreOffice 4.3.

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.
Comment 7 Caolán McNamara 2014-06-04 15:59:44 UTC
and review avail in gerrit for 4-2
Comment 8 Commit Notification 2014-06-05 20:34:14 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

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

Resolves: fdo#78477 ensure offset + sizeof(value) is in bounds


It will be available in LibreOffice 4.2.6.

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.
Comment 9 Robinson Tryon (qubit) 2015-12-17 08:02:17 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]