ubiquity crashed with SIGSEGV in _int_malloc()

Bug #1303516 reported by Hiren Gandhi on 2014-04-07
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
HarfBuzz
Unknown
Unknown
harfbuzz (Ubuntu)
High
Unassigned
Trusty
High
Iain Lane

Bug Description

[ Description ]

Memory corruption when rendering Myanmar text leeds to a crash

[ Test case ]

IMPORTANT NOTE: below will modify currently running locale/keyboard be prepared to restore it, e.g. by enabling keyboard indicator to change keyboard back to normal.

1. Install ubiquity on a desktop or boot from an ISO
  $ sudo apt-get install ubiquity-frontend-gtk
2. If you run on a desktop start ubiquity with:
  $ ubiquity --greeter
3. Scroll to the bottom of the language list, click on 5th or 4th from the bottom

ACTUAL RESULT
python3 segmentation fault:
*** Error in `/usr/bin/python3': malloc(): memory corruption: 0x0000000003b33d80 ***
Segmentation fault (core dumped)

EXPECTED RESULT
No crash

[ QA ]

Check that the test case doesn't crash after applying the SRU

[ Original Report ]

I was testing a daily imagine of Ubuntu Gnome 14.04 (Live Image test), and was just checking out the languages on the initial boot up. When i was trying to click on the 4th language from the bottom ubiquitity crashed to give me this error.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: ubiquity 2.17.10
ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
Uname: Linux 3.13.0-23-generic x86_64
ApportVersion: 2.14.1-0ubuntu1
Architecture: amd64
CasperVersion: 1.339
Date: Mon Apr 7 00:06:38 2014
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InstallCmdLine: file=/cdrom/preseed/ubuntu-gnome.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
InterpreterPath: /usr/bin/python3.4
LiveMediaBuild: Ubuntu-GNOME 14.04 LTS "Trusty Tahr" - Daily amd64 (20140406)
ProcCmdline: /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --greeter --only
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
SegvAnalysis:
 Segfault happened at: 0x7f3d8a71dd71 <_int_malloc+689>: mov %r14,0x10(%r9)
 PC (0x7f3d8a71dd71) ok
 source "%r14" ok
 destination "0x10(%r9)" (0x180000001210) not located in a known VMA region (needed writable region)!
SegvReason: writing unknown VMA
Signal: 11
SourcePackage: ubiquity
StacktraceTop:
 _int_malloc (av=0x7f3d8aa5c760 <main_arena>, bytes=1824) at malloc.c:3489
 __GI___libc_malloc (bytes=1824) at malloc.c:2891
 ?? () from /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
 gr_make_font_with_ops () from /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
 gr_make_font_with_advance_fn () from /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
Title: ubiquity crashed with SIGSEGV in _int_malloc()
UpgradeStatus: No upgrade log present (probably fresh install)
UpstartUbiquity: debconf: DbDriver "templatedb": /var/cache/debconf/templates.dat is locked by another process: Resource temporarily unavailable
UserGroups:

Created attachment 94183
sample file that crashes gedit

gedit crashes when loading the attached file with graphite2 support enabled.

Downstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=998812

Hiren Gandhi (hirenngandhi) wrote :
information type: Private → Public
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1303516

tags: added: iso-testing

StacktraceTop:
 _int_malloc (av=0x7f3d8aa5c760 <main_arena>, bytes=1824) at malloc.c:3489
 __GI___libc_malloc (bytes=1824) at malloc.c:2891
 gralloc<float> (n=456) at /build/buildd/graphite2-1.2.4/src/inc/Main.h:88
 graphite2::Font::Font (this=0x1d5bd70, ppm=<optimized out>, f=..., appFontHandle=<optimized out>, ops=<optimized out>) at /build/buildd/graphite2-1.2.4/src/Font.cpp:46
 gr_make_font_with_ops (ppm=15024, appFontHandle=0x67d0d10, font_ops=font_ops@entry=0x7fff72772f50, face=0x2512f20) at /build/buildd/graphite2-1.2.4/src/gr_font.cpp:52

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Jean-Baptiste Lallement (jibel) wrote :

Confirmed with Ubuntu Trusty Desktop 20140407 amd64 by clicking on the 4th language from the bottom of the list in ubiquity-dm

Changed in ubiquity (Ubuntu):
importance: Medium → High
status: New → Triaged
affects: ubiquity (Ubuntu) → graphite2 (Ubuntu)
Dimitri John Ledkov (xnox) wrote :

below will modify currently running locale/keyboard be prepared to restore it, e.g. by enabling keyboard indicator to change keyboard back to normal.

$ sudo apt-get install ubiquity-frontend-gtk
$ ubiquity --greeter

scroll to the bottom of the language list, click on 5th or 4th from the bottom, thus causing python3 segmentation fault:
$ ubiquity --greeter
*** Error in `/usr/bin/python3': malloc(): memory corruption: 0x0000000003b33d80 ***
Segmentation fault (core dumped)

description: updated
Changed in graphite2 (Ubuntu Trusty):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
milestone: none → ubuntu-14.04
Iain Lane (laney) wrote :

Having a look, not sure I'm going to be able to track down a memory corruption in this stack (pango/harfbuzz/graphite2) though, so will forward upstream.

Changed in graphite2 (Ubuntu Trusty):
assignee: Canonical Desktop Team (canonical-desktop-team) → Iain Lane (laney)

Created attachment 97348
backtrace

I can't be very useful in this bug report, I'm afraid.

Originally reported at
  https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1303516

I didn't reproduce this in another way

1. Install ubiquity on a desktop or boot from an ISO*
  $ sudo apt-get install ubiquity-frontend-gtk
2. If you run on a desktop start ubiquity with:
  $ ubiquity --greeter
3. Scroll to the bottom of the language list, click on 5th or 4th from the bottom

That is the entry for Myanmar (or Burmese, can't read it), unless I'm mistaken. Still happens with HB_SHAPER_LIST=ot.

For what it's worth, I've attached a bt full.

* http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64.iso

At your service for debugging, if you've got ideas and can't reproduce for any reason.

Iain Lane (laney) wrote :

For me, running on my desktop, it's the 5th language from the bottom. We think it's Myanmar (Burmese).

Any ideas how we could run valgrind on this and get useful results?

Changed in harfbuzz:
importance: Unknown → Medium
status: Unknown → Confirmed

It works if I build without graphite2

Launchpad Janitor (janitor) wrote :

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

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

I believe this should fix it:

commit 6ae13f257c3986517c097fa666ab9f58bdc918b5
Author: Behdad Esfahbod <email address hidden>
Date: Fri May 30 17:38:14 2014 -0400

    [graphite2] Fix cluster mapping

    Patch from Martin Hosken. I expect this to fix the following bugs:

    https://bugs.freedesktop.org/show_bug.cgi?id=75076
    https://bugzilla.gnome.org/show_bug.cgi?id=723582
    https://bugzilla.redhat.com/show_bug.cgi?id=998812

mhosken (martin-hosken) wrote :

A couple of initial queries:

Is there any way we can find out what the font was that was being initialised when the crash occurred? I ask because if the font isn't a graphite font, then what was causing a graphite font to try to be created? Looking at the input text being Burmese, I'll assume it's font linked Padauk.

The ppm value of 15024 being passed here in the source stack trace is suspicious (even if divided by 64 it's still 234pt which is a biiiig font). Not that such a big value alone would cause the crash. But has some corruption occurred earlier?

#4 0x00007f3d808922d2 in gr_make_font_with_ops (ppm=15024, appFontHandle=0x67d0d10, font_ops=font_ops@entry=0x7fff72772f50, face=0x2512f20) at /build/buildd/graphite2-1.2.4/src/gr_font.cpp:52

In the main stack trace, the size value here looks suitably crazy but that could be due to some wandering in the long tall grass (although *how* anyone can get malloc to crash quite so impressively is an interesting question in its own right):

#0 _int_malloc (av=0x7f3d8aa5c760 <main_arena>, bytes=1824) at malloc.c:3489
        iters = <optimized out>
        nb = 1840
        idx = 76
        bin = <optimized out>
        victim = 0x67ec860
        size = 39582418614272

Is this implying a post free memory access to mess up the free list? Are there any other reasons that malloc could go crazy like this? I assume a modern malloc doesn't do anything nice like use the last element on the free list for the next malloc? So the corruption and following usage could be far apart?

mhosken (martin-hosken) wrote :

In addition. If this is a memory corruption bug, is running the test under valgrind of any use?

mhosken (martin-hosken) wrote :

When I ran the test, I got not failure. But I did notice that when I ran the test using valgrind (still with no failure) valgrind reported a number of memory problems in python3.4. No errors were reported from anywhere in gtk or lower (pango, graphite, etc.). The command I used to test was:

valgrind --log-file=ubiquity.log ubiquity --greeter

Maybe a fixed python has fixed this bug?
Please retest with newer python3

CSRedRat (csredrat) wrote :

When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?

We believe this is fixed now. Please test.

*** This bug has been marked as a duplicate of bug 75076 ***

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

Iain Lane (laney) on 2014-07-21
Changed in graphite2 (Ubuntu):
status: Triaged → Invalid
Changed in graphite2 (Ubuntu Trusty):
status: Triaged → Invalid
Changed in harfbuzz (Ubuntu):
status: Confirmed → Triaged
Changed in harfbuzz (Ubuntu Trusty):
importance: Undecided → High
Changed in graphite2 (Ubuntu):
assignee: Iain Lane (laney) → nobody
Changed in graphite2 (Ubuntu Trusty):
assignee: Iain Lane (laney) → nobody
Changed in harfbuzz (Ubuntu Trusty):
status: Confirmed → In Progress
Changed in harfbuzz (Ubuntu):
importance: Undecided → High
Changed in harfbuzz (Ubuntu Trusty):
assignee: nobody → Iain Lane (laney)
Iain Lane (laney) wrote :

Uploaded to Utopic and Trusty, awaiting review in the latter.

Iain Lane (laney) on 2014-07-21
description: updated
Changed in harfbuzz:
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package harfbuzz - 0.9.29-1ubuntu2

---------------
harfbuzz (0.9.29-1ubuntu2) utopic; urgency=medium

  * No-change rebuild to drop version of glib2.0-udeb dep
 -- Iain Lane <email address hidden> Mon, 21 Jul 2014 22:30:44 +0100

Changed in harfbuzz (Ubuntu):
status: Triaged → Fix Released

Hello Hiren, or anyone else affected,

Accepted harfbuzz into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/harfbuzz/0.9.27-1ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in harfbuzz (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in harfbuzz:
importance: Medium → Undecided
status: Invalid → New
importance: Undecided → Unknown
status: New → Unknown
Changed in harfbuzz:
importance: Unknown → Undecided
status: Unknown → New
Mathew Hodson (mathew-hodson) wrote :

Verified that ubiquity does not crash with libharfbuzz0b 0.9.27-1ubuntu1 from trusty-proposed.

tags: added: verification-done
removed: verification-needed
Changed in harfbuzz:
importance: Undecided → Unknown
status: New → Unknown
Changed in harfbuzz:
importance: Unknown → Medium
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package harfbuzz - 0.9.27-1ubuntu1

---------------
harfbuzz (0.9.27-1ubuntu1) trusty; urgency=medium

  * debian/patches/0001-graphite2-Fix-cluster-mapping.patch: Cherry-pick a
    patch from upstream (in 0.9.30) to fix a crasher in the graphite2 engine
    when rendering some scripts (e.g. happens on Myanmar text). (LP: #1303516)
 -- Iain Lane <email address hidden> Mon, 21 Jul 2014 11:52:19 +0100

Changed in harfbuzz (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for harfbuzz has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in harfbuzz:
importance: Medium → Unknown
status: Fix Released → Unknown
importance: Unknown → Undecided
status: Unknown → New
Changed in harfbuzz:
importance: Undecided → Unknown
status: New → Unknown
Changed in graphite2 (Ubuntu):
milestone: ubuntu-14.04 → none
Changed in graphite2 (Ubuntu Trusty):
milestone: ubuntu-14.04 → none
Changed in harfbuzz:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: graphite2 (Ubuntu)
no longer affects: graphite2 (Ubuntu Trusty)
Changed in harfbuzz:
importance: Undecided → Unknown
status: New → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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