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.
Created attachment 479388 [details] File: backtrace
Created attachment 479389 [details] The PNG that I tried to open. (opened nicely the second time)
> #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\*
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
> #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.
Several recent dups for gnome-shell, updating the version to Fedora 16
*** Bug 758662 has been marked as a duplicate of this bug. ***
*** Bug 766416 has been marked as a duplicate of this bug. ***
*** Bug 766418 has been marked as a duplicate of this bug. ***
*** Bug 668978 has been marked as a duplicate of this bug. ***
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.
*** Bug 882100 has been marked as a duplicate of this bug. ***
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)
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
Changing from F16' to F18' based on comment 13.
Right after start up. backtrace_rating: 4 Package: gnome-shell-3.6.2-6.fc18 OS Release: Fedora release 18 (Spherical Cow)
*** Bug 1003579 has been marked as a duplicate of this bug. ***
*** Bug 994753 has been marked as a duplicate of this bug. ***
*** Bug 991054 has been marked as a duplicate of this bug. ***
*** Bug 988896 has been marked as a duplicate of this bug. ***
*** Bug 977517 has been marked as a duplicate of this bug. ***
*** Bug 976650 has been marked as a duplicate of this bug. ***
*** Bug 977478 has been marked as a duplicate of this bug. ***
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
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
Workarounds in the application software are not the right solution for the underlying library problem.
(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?
(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.
(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?
(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.
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.
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
Let me take a look into this. My gut feeling is that the discussion has gone in a totally wrong direction.
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.
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.
For the shaping failure, it displayed nothing else than a single circle/ellipse.
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.
$ geeqie --debug ./test.dot.svg 2>&1 | tail ... 0.250233 (+00000.000050) pixbuf renderer done 0x7fd3b08d0130 FWIW, eog is slower.
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.
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.
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?
(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.
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/
> 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...
(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
*** Bug 1004584 has been marked as a duplicate of this bug. ***
Thanks! Waiting for the patch.
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
Thanks. I'll follow up with you on the upstream bug.
*** Bug 1005910 has been marked as a duplicate of this bug. ***
*** Bug 1015315 has been marked as a duplicate of this bug. ***
*** Bug 1030790 has been marked as a duplicate of this bug. ***
*** Bug 855582 has been marked as a duplicate of this bug. ***
*** Bug 877535 has been marked as a duplicate of this bug. ***
*** Bug 948018 has been marked as a duplicate of this bug. ***
*** Bug 991813 has been marked as a duplicate of this bug. ***
*** Bug 991834 has been marked as a duplicate of this bug. ***
*** Bug 1004315 has been marked as a duplicate of this bug. ***
*** Bug 879411 has been marked as a duplicate of this bug. ***
*** Bug 982187 has been marked as a duplicate of this bug. ***
*** Bug 985672 has been marked as a duplicate of this bug. ***
*** Bug 1006073 has been marked as a duplicate of this bug. ***
*** Bug 1015837 has been marked as a duplicate of this bug. ***
*** Bug 1017470 has been marked as a duplicate of this bug. ***
*** Bug 1027271 has been marked as a duplicate of this bug. ***
*** Bug 1031338 has been marked as a duplicate of this bug. ***
*** Bug 1031567 has been marked as a duplicate of this bug. ***
*** Bug 1039361 has been marked as a duplicate of this bug. ***
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.
Most of the recent dupes are for F19, but bug 1004315 is for F20.
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
I have developed a patchset to fix this and similar issues. See: http://www.mail-archive.com/freetype-devel@nongnu.org/msg06758.html
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.
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.
https://bugzilla.redhat.com/buglist.cgi?quicksearch=gray_find_cell
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
*** Bug 1218852 has been marked as a duplicate of this bug. ***
*** Bug 1054428 has been marked as a duplicate of this bug. ***
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
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
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.