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
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.
(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.
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
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.
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.
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.
and review avail in gerrit for 4-2
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]