Bug 678397

Summary: gray_find_cell() - longjmp causes uninitialized stack frame
Product: [Fedora] Fedora Reporter: Egon Kastelijn <redhat2>
Component: freetypeAssignee: Marek Kašík <mkasik>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: awilliam, behdad, bugs.michael, dblechte, dcharlespyle, fonts-bugs, glad08, hajoelbers, joey10946, joshua, jruiz, jsedlak, jskarvad, kevin, klem_hmedeh, leandrolnh, lionelfelicite, lood.rooliza, marbolangos, mats, mkasik, m, mmunchinski, mpetlan, otaylor, otte, psychon, reinouts, rhelbugzilla, robxu9, sgrubb, ssahani, stefano.manocchio, tomg, wanwizard, zgeorge.zhao
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:85b0375289071beb43825219e4f328845d0d5f58
Fixed In Version: freetype-2.5.5-2.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-09 06:29:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
File: backtrace
none
The PNG that I tried to open. (opened nicely the second time) none

Description Egon Kastelijn 2011-02-17 14:40:33 EST
abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: geeqie tmp/total.png
component: geeqie
executable: /usr/bin/geeqie
kernel: 2.6.35.11-83.fc14.x86_64
package: geeqie-1.0-4.fc14
reason: Process /usr/bin/geeqie was killed by signal 6 (SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1297971441
uid: 500

comment
-----
I was opening a PNG file from the command-line.
geeqie tmp/total.png &

How to reproduce
-----
I was opening a PNG file from the command-line.
  geeqie tmp/total.png &
I don't think I can reproduce this problem, because I use geeqie a lot, and this is the first time it crashed on a PNG file.
Comment 1 Egon Kastelijn 2011-02-17 14:40:38 EST
Created attachment 479388 [details]
File: backtrace
Comment 2 Egon Kastelijn 2011-02-17 14:48:08 EST
Created attachment 479389 [details]
The PNG that I tried to open. (opened nicely the second time)
Comment 3 Michael Schwendt 2011-02-17 16:20:21 EST
> #6  0x000000368be59b25 in gray_find_cell (worker=0xfffffffffffff780)
> at /usr/src/debug/freetype-2.4.2/src/smooth/ftgrays.c:483

According to the backtrace, it crashed deep in freetype.

Can you give details about what freetype you've got installed?
e.g.:  rpm -qa freetype\*
Comment 4 Egon Kastelijn 2011-02-18 00:31:24 EST
Hi Michael,

My compliments for your quick response!
;)

# rpm -qa freetype
freetype-2.4.2-4.fc14.i686
freetype-2.4.2-4.fc14.x86_64
#

kind regards,

   Egon
Comment 5 Michael Schwendt 2011-02-18 04:21:22 EST
> #37 0x0000003692b411a2 in gtk_label_expose at gtklabel.c:3570
> #36 0x00007f955dd1ade0 in clearlooks_style_draw_layout at src/clearlooks_style.c:1877
> #35 0x000000369322e1c7 in IA__gdk_draw_layout at gdkpango.c:1061
> pango
> cairo
> freetype

That's way outside Geeqie's code and not related to the attached .png either.
Comment 6 Owen Taylor 2011-12-16 13:15:08 EST
Several recent dups for gnome-shell, updating the version to Fedora 16
Comment 7 Owen Taylor 2011-12-16 13:16:23 EST
*** Bug 758662 has been marked as a duplicate of this bug. ***
Comment 8 Owen Taylor 2011-12-16 13:16:38 EST
*** Bug 766416 has been marked as a duplicate of this bug. ***
Comment 9 Owen Taylor 2011-12-16 13:16:47 EST
*** Bug 766418 has been marked as a duplicate of this bug. ***
Comment 10 abrt-bot 2012-03-20 12:32:26 EDT
*** Bug 668978 has been marked as a duplicate of this bug. ***
Comment 11 abrt-bot 2012-03-30 08:15:58 EDT
Backtrace analysis found this bug to be similar to some already closed bugs from other components. You might want to check those bugs for additional information.

Bugs which were found to be similar to this bug: 
  gnome-shell: bug #701276
  totem: bug #551052

This comment is automatically generated.
Comment 12 Michael Schwendt 2012-11-30 05:35:43 EST
*** Bug 882100 has been marked as a duplicate of this bug. ***
Comment 13 D. Charles Pyle 2012-12-23 22:24:54 EST
Logged into GNOME Shell. Found this error waiting in the tray. Don't know what caused it.

backtrace_rating: 4
Package: gnome-shell-3.6.2-6.fc18
OS Release: Fedora release 18 (Spherical Cow)
Comment 14 Fedora End Of Life 2013-01-16 10:52:36 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Michael Schwendt 2013-01-16 11:29:41 EST
Changing from F16' to F18' based on comment 13.
Comment 16 Bill 2013-01-24 12:32:05 EST
Right after start up.

backtrace_rating: 4
Package: gnome-shell-3.6.2-6.fc18
OS Release: Fedora release 18 (Spherical Cow)
Comment 17 Michael Schwendt 2013-09-02 10:44:50 EDT
*** Bug 1003579 has been marked as a duplicate of this bug. ***
Comment 18 Michael Schwendt 2013-09-02 10:44:57 EDT
*** Bug 994753 has been marked as a duplicate of this bug. ***
Comment 19 Michael Schwendt 2013-09-02 10:45:07 EDT
*** Bug 991054 has been marked as a duplicate of this bug. ***
Comment 20 Michael Schwendt 2013-09-02 10:45:13 EDT
*** Bug 988896 has been marked as a duplicate of this bug. ***
Comment 21 Michael Schwendt 2013-09-02 10:45:13 EDT
*** Bug 977517 has been marked as a duplicate of this bug. ***
Comment 22 Michael Schwendt 2013-09-02 10:45:16 EDT
*** Bug 976650 has been marked as a duplicate of this bug. ***
Comment 23 Michael Schwendt 2013-09-02 10:46:24 EDT
*** Bug 977478 has been marked as a duplicate of this bug. ***
Comment 24 Marek Kašík 2013-09-03 10:29:52 EDT
The problem reproduces for me quite often with the reproducer from #977478. It is a thread-related problem. It doesn't crash if I compile geeqie with "--disable-threads" and with ifdef-ed all g_mutex_{un}lock() by "#ifdef HAVE_GTHREAD".
I suppose that the problem with cinnamon is similar.

Marek
Comment 25 Michael Schwendt 2013-09-03 11:06:58 EDT
I don't want this ticket, as it collects duplicates for

  gnome-shell
  totem
  evince
  cinnamon

and not just geeqie. See comment 6 for example.

More gnome-shell crashes because of this:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=gray_find_cell&list_id=1673432
Comment 26 Jaroslav Škarvada 2013-09-03 11:55:36 EDT
Workarounds in the application software are not the right solution for the underlying library problem.
Comment 27 Marek Kašík 2013-09-03 11:56:43 EDT
(In reply to Jaroslav Škarvada from comment #26)
> Workarounds in the application software are not the right solution for the
> underlying library problem.

Could you be more specific?
Comment 28 Jaroslav Škarvada 2013-09-03 12:05:27 EDT
(In reply to Marek Kašík from comment #27)
> (In reply to Jaroslav Škarvada from comment #26)
> > Workarounds in the application software are not the right solution for the
> > underlying library problem.
> 
> Could you be more specific?

Recompilation without threading support.
Comment 29 Steve Tyler 2013-09-03 12:15:47 EDT
(In reply to Marek Kašík from comment #24)
> The problem reproduces for me quite often with the reproducer from #977478.
> It is a thread-related problem. It doesn't crash if I compile geeqie with
> "--disable-threads" and with ifdef-ed all g_mutex_{un}lock() by "#ifdef
> HAVE_GTHREAD".
> I suppose that the problem with cinnamon is similar.
> 
> Marek

Are you are recompiling with "--disable-threads" to help diagnose the problem or as a workaround?
Comment 30 Marek Kašík 2013-09-03 13:18:05 EDT
(In reply to Steve Tyler from comment #29)
> (In reply to Marek Kašík from comment #24)
> > The problem reproduces for me quite often with the reproducer from #977478.
> > It is a thread-related problem. It doesn't crash if I compile geeqie with
> > "--disable-threads" and with ifdef-ed all g_mutex_{un}lock() by "#ifdef
> > HAVE_GTHREAD".
> > I suppose that the problem with cinnamon is similar.
> > 
> > Marek
> 
> Are you are recompiling with "--disable-threads" to help diagnose the
> problem or as a workaround?

Just to diagnose the problem.
Comment 31 Michael Schwendt 2013-09-03 13:59:03 EDT
Apparently freetype isn't thread-safe, and the stack on top if it doesn't take precautions: pango -> cairo -> freetype    Geeqie, for example, doesn't use freetype directly, but only indirectly via gtk, gdk-pixbuf2 and a bit of pango.
Comment 32 Steve Tyler 2013-09-03 14:17:07 EDT
FreeType 2 is supposedly thread-safe.[1]
However, there is a caveat for FT_Library.[2]

[1] How portable is FreeType 2?
...
    The library doesn't use any static writable data at all, making it an ideal choice on various embedded systems (e.g., it can be run from ROM directly). It is completely thread-safe too.
...
http://www.freetype.org/freetype2/docs/ft2faq.html


[2] FT_Library
Defined in FT_FREETYPE_H (freetype/freetype.h).
...
In multi-threaded applications, make sure that the same FT_Library object or any of its children doesn't get accessed in parallel.
...
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html


Found with a google search:
http://www.google.com/#q=thread+safe+site:www.freetype.org
Comment 33 Behdad Esfahbod 2013-09-03 14:39:11 EDT
Let me take a look into this.  My gut feeling is that the discussion has gone in a totally wrong direction.
Comment 34 Behdad Esfahbod 2013-09-03 16:50:37 EDT
What's the latest version of fedora that reproduces this?  I made the text rendering stack (ie. below Pango) threadsafe very recently.  I cannot reproduce the crash with all the latest library, but CAN reproduce with much older libraries.

That said, the crash I get is in cairo...

BTW, with the latest libraries, geeqie renders the SVG file as broken, whereas rsvg-view-3 renders it fine.

Please report versions of freetype, fontconfig, cairo, and pango.
Comment 35 Michael Schwendt 2013-09-03 17:06:16 EDT
If only I could reproduce it reliably. It's *very* difficult here, but I've used Fedora 20 in bug 1003579 comment 1 on Sep 2nd.

While replying here, I took ~30 tries on an up-to-date F20:

  freetype-2.5.0-3.fc20.x86_64
  cairo-1.12.16-1.fc20.x86_64
  pango-1.35.2-2.fc20.x86_64
  fontconfig-2.10.95-3.fc20.x86_64

> geeqie renders the SVG file as broken

Cannot confirm, and I've compared with rsvg-view-3 now too. I always get the same (a)<=>(b) "whatever" thing.

When retrying many many times, rarely I get something like the following on the terminal

| (geeqie:28212): Pango-WARNING **: shaping failure, expect ugly output.
| shape-engine='BasicEngineFc', font='Nimbus Roman No9 L 13.9990234375',
| text='b'

and the SVG then doesn't display correctly. I assume it's a side-effect of something going wrong.
Comment 36 Michael Schwendt 2013-09-03 17:08:26 EDT
For the shaping failure, it displayed nothing else than a single circle/ellipse.
Comment 37 Behdad Esfahbod 2013-09-03 17:20:48 EDT
Ok, the broken load was my bad setup.

Image loads very slow (.5s or so) in geeqie.  Do you see that too?

The shaping failure sounds relevant...  Trying to reproduce.
Comment 38 Michael Schwendt 2013-09-03 17:32:12 EDT
$ geeqie --debug ./test.dot.svg 2>&1 | tail
...
    0.250233 (+00000.000050) pixbuf renderer done 0x7fd3b08d0130

FWIW, eog is slower.
Comment 39 Behdad Esfahbod 2013-09-03 17:45:51 EDT
Humm.  I don't get that line in the debug output.  I get:

    1.789624 (+00000.000453) layout_editors_reload_idle_cb: setup_editors done
monitor /home/behdad/threading-bug-rh678397
monitor /home/behdad/threading-bug-rh678397/LiberationMono-Bold.svg
image activate focus_in 0
collection manager flushing
collection manager is up to date
Unregister realtime 1 /home/behdad/threading-bug-rh678397/LiberationMono-Bold.svg
    7.101695 (+00005.312071) image reset
    7.101707 (+00000.000012) read ahead cancelled for :null
Unregister realtime 1 /home/behdad/threading-bug-rh678397

where the 7s is the time until I closed the app.
Comment 40 Michael Schwendt 2013-09-04 03:05:56 EDT
It's level 1 debug output that cannot go missing. Not even increasing the debug level would help (there would only be more noise with e.g. --debug=255), and the pixbuf renderer is too essential for every image. One can see that with

$ geeqie --debug 2>&1 | grep "renderer done"
    0.254572 (+00000.000047) pixbuf renderer done 0x7f9bf4d90130
    1.418905 (+00000.000050) pixbuf renderer done 0x7f9bf4d90130
    1.636936 (+00000.000041) pixbuf renderer done 0x7f9bf4d90130
...

when switching through multiple images.
Comment 41 Steve Tyler 2013-09-04 05:02:05 EDT
This backtrace shows two threads with the same worker pointer
(Bug 977517, Attachment 764742 [details]):

Thread 3 (Thread 0x7fcf50cba9c0 (LWP 2278)):
#0  gray_find_cell (worker=0x10d7b50) at /usr/src/debug/freetype-2.4.11/src/smooth/ftgrays.c:480

Thread 1 (Thread 0x7fcf43ccd700 (LWP 2280)):
#0  gray_find_cell (worker=0x10d7b50) at /usr/src/debug/freetype-2.4.11/src/smooth/ftgrays.c:480

Marek, can you suggest a way that could happen?
Comment 42 Marek Kašík 2013-09-04 05:35:26 EDT
(In reply to Steve Tyler from comment #41)
> This backtrace shows two threads with the same worker pointer
> (Bug 977517, Attachment 764742 [details]):
> 
> Thread 3 (Thread 0x7fcf50cba9c0 (LWP 2278)):
> #0  gray_find_cell (worker=0x10d7b50) at
> /usr/src/debug/freetype-2.4.11/src/smooth/ftgrays.c:480
> 
> Thread 1 (Thread 0x7fcf43ccd700 (LWP 2280)):
> #0  gray_find_cell (worker=0x10d7b50) at
> /usr/src/debug/freetype-2.4.11/src/smooth/ftgrays.c:480
> 
> Marek, can you suggest a way that could happen?

It can be there because grayPWorker is part of gray_PRaster, gray_PRaster is as a FT_Raster (see gray_raster_reset()) part of FT_Renderer which is part of FT_Library. The FT_Library is used by multiple threads in cairo.
Maybe some mutexes in cairo could help.
Comment 43 Steve Tyler 2013-09-04 06:08:32 EDT
Nice work, Marek. That's way more than I could have figured out. :-)

The only cairo file referring to FT_Library appears to be cairo-ft-font.c:

$ find cairo-1.12.14/src -name '*.[ch]' | xargs grep FT_Library
cairo-1.12.14/src/cairo-ft-font.c:    FT_Library ft_library;
cairo-1.12.14/src/cairo-ft-font.c:    FT_Library library = glyphslot->library;
cairo-1.12.14/src/cairo-ft-font.c:	FT_Library_SetLcdFilter (library, lcd_filter);
cairo-1.12.14/src/cairo-ft-font.c:	FT_Library_SetLcdFilter (library, FT_LCD_FILTER_NONE);

Source is from here:
http://cairographics.org/releases/
Comment 44 Marek Kašík 2013-09-04 06:57:01 EDT
> It can be there because grayPWorker is part of gray_PRaster, gray_PRaster is
> as a FT_Raster (see gray_raster_reset()) part of FT_Renderer which is part
> of FT_Library. The FT_Library is used by multiple threads in cairo.
> Maybe some mutexes in cairo could help.

I tried to place mutexes around uses of the FT_Library in cairo but it doesn't help. I continue on this...
Comment 45 Marek Kašík 2013-09-05 10:54:27 EDT
(In reply to Marek Kašík from comment #44)
> > It can be there because grayPWorker is part of gray_PRaster, gray_PRaster is
> > as a FT_Raster (see gray_raster_reset()) part of FT_Renderer which is part
> > of FT_Library. The FT_Library is used by multiple threads in cairo.
> > Maybe some mutexes in cairo could help.
> 
> I tried to place mutexes around uses of the FT_Library in cairo but it
> doesn't help. I continue on this...

I tried to place more calls of Freetype's functions in Cairo to the mutex and it helps. The geeqie doesn't crash anymore with it. I'll prepare a patch and post it here and upstream (I want to look at which functions really need to be locked by the mutex yet).

Regards

Marek
Comment 46 Behdad Esfahbod 2013-09-05 12:00:27 EDT
*** Bug 1004584 has been marked as a duplicate of this bug. ***
Comment 47 Behdad Esfahbod 2013-09-05 12:18:18 EDT
Thanks!  Waiting for the patch.
Comment 48 Marek Kašík 2013-09-06 09:42:16 EDT
Hi,

I've created an upstream bug for this issue (see https://bugs.freedesktop.org/show_bug.cgi?id=69034). The patch fixing it is attached there.
I've changed my mind a little since yesterday. Locking every dangerous usage of freetype's functions by mutex would lock almost whole freetype code in cairo. Not talking about possible usage of some structures outside of cairo.
So I did what freetype recommends. It recommends to have FT_Library for each thread. I created a hash table which contains FT_Library for each thread. Thread IDs are used as keys to this hash table.

geeqie doesn't crash with the patch applied.

I'm reassigning this to cairo.

Regards

Marek
Comment 49 Behdad Esfahbod 2013-09-06 13:55:06 EDT
Thanks.  I'll follow up with you on the upstream bug.
Comment 50 Marek Kašík 2013-09-10 05:27:56 EDT
*** Bug 1005910 has been marked as a duplicate of this bug. ***
Comment 51 Behdad Esfahbod 2013-11-15 14:17:15 EST
*** Bug 1015315 has been marked as a duplicate of this bug. ***
Comment 52 Behdad Esfahbod 2013-11-15 14:17:29 EST
*** Bug 1030790 has been marked as a duplicate of this bug. ***
Comment 53 Behdad Esfahbod 2013-11-15 14:17:29 EST
*** Bug 855582 has been marked as a duplicate of this bug. ***
Comment 54 Behdad Esfahbod 2013-11-15 14:17:31 EST
*** Bug 877535 has been marked as a duplicate of this bug. ***
Comment 55 Behdad Esfahbod 2013-11-15 14:17:34 EST
*** Bug 948018 has been marked as a duplicate of this bug. ***
Comment 56 Behdad Esfahbod 2013-11-15 14:17:38 EST
*** Bug 991813 has been marked as a duplicate of this bug. ***
Comment 57 Behdad Esfahbod 2013-11-15 14:17:42 EST
*** Bug 991834 has been marked as a duplicate of this bug. ***
Comment 58 Behdad Esfahbod 2013-11-15 14:17:45 EST
*** Bug 1004315 has been marked as a duplicate of this bug. ***
Comment 59 Behdad Esfahbod 2013-11-15 14:17:48 EST
*** Bug 879411 has been marked as a duplicate of this bug. ***
Comment 60 Behdad Esfahbod 2013-11-15 14:17:51 EST
*** Bug 982187 has been marked as a duplicate of this bug. ***
Comment 61 Behdad Esfahbod 2013-11-15 14:17:53 EST
*** Bug 985672 has been marked as a duplicate of this bug. ***
Comment 62 Behdad Esfahbod 2013-11-15 14:17:54 EST
*** Bug 1006073 has been marked as a duplicate of this bug. ***
Comment 63 Behdad Esfahbod 2013-11-15 14:18:07 EST
*** Bug 1015837 has been marked as a duplicate of this bug. ***
Comment 64 Behdad Esfahbod 2013-11-15 14:18:11 EST
*** Bug 1017470 has been marked as a duplicate of this bug. ***
Comment 65 Behdad Esfahbod 2013-11-15 14:18:13 EST
*** Bug 1027271 has been marked as a duplicate of this bug. ***
Comment 66 Behdad Esfahbod 2013-11-17 12:11:20 EST
*** Bug 1031338 has been marked as a duplicate of this bug. ***
Comment 67 Marek Kašík 2013-11-18 07:27:49 EST
*** Bug 1031567 has been marked as a duplicate of this bug. ***
Comment 68 Behdad Esfahbod 2013-12-08 20:01:18 EST
*** Bug 1039361 has been marked as a duplicate of this bug. ***
Comment 69 Fedora End Of Life 2013-12-21 03:27:05 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 70 Michael Schwendt 2013-12-21 07:49:18 EST
Most of the recent dupes are for F19, but bug 1004315 is for F20.
Comment 71 Steve Grubb 2014-04-20 17:22:34 EDT
Thought I'd report the problem still exists on F20. While hovering over the accessories menu item in cinnamon, it reset. Then abrt reported a problem. This is a snippet of the back trace:

Missing separate debuginfos, use: debuginfo-install cinnamon-2.0.14-15.fc20.x86_64
(gdb) bt
#0  _int_free (av=0x7f97ac000020, p=0x7f97ac001ac0, have_lock=0)
    at malloc.c:3907
#1  0x00007f97e77cd90f in ft_glyphslot_free_bitmap (slot=0x7f97ac049fb0)
    at /usr/src/debug/freetype-2.5.0/src/base/ftobjs.c:297
#2  0x00007f97e77cfb75 in ft_glyphslot_clear (slot=0x7f97ac049fb0)
    at /usr/src/debug/freetype-2.5.0/src/base/ftobjs.c:343
#3  FT_Load_Glyph (face=face@entry=0x7f97ac049400, 
    glyph_index=glyph_index@entry=48, load_flags=load_flags@entry=512)
    at /usr/src/debug/freetype-2.5.0/src/base/ftobjs.c:610
#4  0x00007f97ed846ace in _cairo_ft_scaled_glyph_init (
    abstract_font=0x7f97ac014570, scaled_glyph=0x7f97ac5c4250, 
    info=CAIRO_SCALED_GLYPH_INFO_SURFACE) at cairo-ft-font.c:2249
Comment 72 Behdad Esfahbod 2014-12-30 19:13:45 EST
I have developed a patchset to fix this and similar issues.  See:
http://www.mail-archive.com/freetype-devel@nongnu.org/msg06758.html
Comment 73 Fedora End Of Life 2015-05-29 04:38:19 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 74 Fedora End Of Life 2015-06-29 07:35:46 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 76 Fedora Update System 2015-08-19 07:38:46 EDT
freetype-2.5.5-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/freetype-2.5.5-2.fc22
Comment 77 Marek Kašík 2015-08-19 07:46:00 EDT
*** Bug 1218852 has been marked as a duplicate of this bug. ***
Comment 78 Marek Kašík 2015-08-19 07:54:57 EDT
*** Bug 1054428 has been marked as a duplicate of this bug. ***
Comment 79 Fedora Update System 2015-08-21 22:51:45 EDT
freetype-2.5.5-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update freetype'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/freetype-2.5.5-2.fc22
Comment 80 Matej 2015-10-08 03:48:05 EDT
Another user experienced a similar problem:

when starting first apps after login

reporter:       libreport-2.6.2
backtrace_rating: 4
cmdline:        gnome-shell --sm-client-id 1077bfb4eeca29d224144161761656173100000135680000
crash_function: gray_find_cell
executable:     /usr/bin/gnome-shell
global_pid:     2207
kernel:         4.1.8-200.fc22.x86_64
package:        gnome-shell-3.16.3-1.fc22
reason:         gnome-shell killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            1000
Comment 81 Fedora Update System 2015-10-09 06:29:48 EDT
freetype-2.5.5-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.