After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 135512 - this document causes gpdf to hang and use 100% CPU
this document causes gpdf to hang and use 100% CPU
Status: RESOLVED DUPLICATE of bug 129400
Product: gpdf
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Martin Kretzschmar
Martin Kretzschmar
Depends on:
Blocks:
 
 
Reported: 2004-02-26 16:25 UTC by Jens Knutson
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6

Attachments
This document crashes gpdf 0.123 (63.87 KB, application/pdf)
2004-02-26 16:31 UTC, Jens Knutson 		Details

Description Jens Knutson 2004-02-26 16:25:39 UTC 
The attached document causes gpdf to freeze up and use 100% CPU until
manually killed.  It renders fine in xpdf.  This is with the latest gpdf,
0.123.


Let me know if you need anything else!
Comment 1 Jens Knutson 2004-02-26 16:31:25 UTC 
Created attachment 24814 [details]
This document crashes gpdf 0.123
Comment 2 Luis Villa 2004-02-26 17:05:06 UTC 
Jens, this works fine for me with HEAD. Can you attach a stack trace?
Thanks.
Comment 3 Jens Knutson 2004-02-26 17:14:58 UTC 
Well, it only freezes, never crashes - can I still get a stack trace
from that?

Also, is there anywhere I could get an RPM or at least an SRPM of CVS?
Comment 4 Rémi Cohen-Scali 2004-02-26 22:06:36 UTC 
here is one:
http://www.rcsnet.net/pub/gpdf/gpdf-0.123-0_cvs_0.src.rpm
http://www.rcsnet.net/pub/gpdf/gpdf-0.123-0_cvs_0.i386.rpm (prefix =
/opt/gnome-2.5 so use with caution)
Comment 5 Luis Villa 2004-02-27 15:27:12 UTC 
jens: find the process id (pid) of the process, do 'gdb attach <pid>'
and then do 'bt' at the gdb prompt.
Comment 6 Jens Knutson 2004-03-12 00:53:24 UTC 
Some more info:

1) This freeze still happens with gpdf .124
2) I forgot to mention that it isn't until one views the second page
that it freezes... (whoops)
3) it's the "gnome-pdf-viewer" process that is sucking up the CPU -
"gpdf" process is idle during this
4) I hope I did the backtrace right - I opened gpdf, went to page 2 of
the PDF, got the freeze, then attached gdb to "gnome-pdf-viewer" and
issued the bt command, and finally, attached gdb to "gpdf" and grabbed
the backtrace from that, too.

Anyhow, here you are...

gnome-pdf-viewer:

(gdb) bt

+ Trace 45039

  • #0 RepadBitmap
    from /usr/lib/libfreetype.so.6
  • #1 gray_raster_render
    from /usr/lib/libfreetype.so.6
  • #2 gray_raster_render
    from /usr/lib/libfreetype.so.6
  • #3 FT_Load_Char
    from /usr/lib/libfreetype.so.6
  • #4 ??
  • #5 ??
  • #0 _dl_sysinfo_int80
    from /lib/ld-linux.so.2
  • #1 poll
    from /lib/tls/libc.so.6
  • #2 g_main_loop_get_context
    from /usr/lib/libglib-2.0.so.0
  • #3 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #4 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #5 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #6 main
    at gpdf.c line 165 






Comment 7


Martin Kretzschmar





          2004-03-12 11:10:55 UTC
        



Perfect backtrace, thanks.

It's a known bug in freetype 2.1.7. Your options are: downgrade
freetype to 2.1.5, wait for 2.1.8, or patch freetype 2.1.7
(description in bug #129400)

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