Bug Description

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

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.

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.

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?

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):

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?

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

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.

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.