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 103634 - Crash from gucharmap 0.2
Crash from gucharmap 0.2
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
unspecified
Other other
: Normal normal
: 1.2.2
Assigned To: Owen Taylor
Owen Taylor
: 107590 113332 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-01-16 04:48 UTC by Havoc Pennington
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fixes the crash of the Hebrew module for the U+F1?? character range. (1.55 KB, patch)
2003-03-09 19:49 UTC, Dov Grobgeld
none Details | Review

Description Havoc Pennington 2003-01-16 04:48:19 UTC
Package: pango
Severity: normal
Version: GNOME2.1.90 0.2
Synopsis: Crash from gucharmap 0.2
Bugzilla-Product: pango
Bugzilla-Component: general
BugBuddy-GnomeVersion: 2.0 (2.1.90)
Description:
Scrolling around in gucharmap 0.2 (http://gucharmap.sourceforge.net/)
got this crash.
It looks like it may just be a matter of passing the text in the
backtrace to the 
Hebrew shaper, so going ahead and reporting to pango.


Debugging Information:

Backtrace was generated from '/unst2/bin/gucharmap'

[New Thread 8192 (LWP 29909)]
0x420ae169 in wait4 () from /lib/i686/libc.so.6

Thread 1 (Thread 8192 (LWP 29909))

  • #0 wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    from /lib/i686/libpthread.so.0
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 646
  • #4 __pthread_sighandler
    from /lib/i686/libpthread.so.0
  • #5 <signal handler called>
  • #6 hebrew_shaper_get_next_cluster
    at hebrew-shaper.c line 238
  • #7 hebrew_engine_shape
    at hebrew-xft.c line 151
  • #8 pango_shape
    at shape.c line 47
  • #9 process_item
    at pango-layout.c line 2572
  • #10 process_line
    at pango-layout.c line 2732
  • #11 pango_layout_check_lines
    at pango-layout.c line 3002
  • #12 pango_layout_get_extents_internal
    at pango-layout.c line 1879
  • #13 pango_layout_get_extents
    at pango-layout.c line 2004
  • #14 pango_layout_get_pixel_size
    at pango-layout.c line 2091
  • #15 draw_character
    at charmap.c line 436
  • #16 draw_chartable_from_scratch
    at charmap.c line 549
  • #17 redraw
    at charmap.c line 725
  • #18 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #19 g_closure_invoke
    at gclosure.c line 437
  • #20 signal_emit_unlocked_R
    at gsignal.c line 2822
  • #21 g_signal_emit_valist
    at gsignal.c line 2554
  • #22 g_signal_emit
    at gsignal.c line 2612
  • #23 gtk_adjustment_value_changed
    at gtkadjustment.c line 176
  • #24 gtk_adjustment_set_value
    at gtkadjustment.c line 159
  • #25 gtk_range_internal_set_value
    at gtkrange.c line 2287
  • #26 gtk_range_motion_notify
    at gtkrange.c line 1407
  • #27 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 82
  • #28 g_type_class_meta_marshal
    at gclosure.c line 514
  • #29 g_closure_invoke
    at gclosure.c line 437
  • #30 signal_emit_unlocked_R
    at gsignal.c line 2860
  • #31 g_signal_emit_valist
    at gsignal.c line 2564
  • #32 g_signal_emit
    at gsignal.c line 2612
  • #33 gtk_widget_event_internal
    at gtkwidget.c line 3143
  • #34 gtk_propagate_event
    at gtkmain.c line 2266
  • #35 gtk_main_do_event
    at gtkmain.c line 1501
  • #36 gdk_event_dispatch
    at gdkevents-x11.c line 2017
  • #37 g_main_dispatch
    at gmain.c line 1653
  • #38 g_main_context_dispatch
    at gmain.c line 2197
  • #39 g_main_context_iterate
    at gmain.c line 2278
  • #40 g_main_loop_run
    at gmain.c line 2498
  • #41 gtk_main
    at gtkmain.c line 1091
  • #42 main
    at main.c line 337
  • #43 __libc_start_main
    from /lib/i686/libc.so.6
  • #0 wait4
    from /lib/i686/libc.so.6




------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-01-15 23:48 -------

Reassigning to the default owner of the component, otaylor@redhat.com.

Comment 1 Havoc Pennington 2003-01-16 04:51:23 UTC
Of course, bugzilla completely ate "the text in the backtrace" :-/
I think it's safe to assume it's one of the Hebrew codepoints.
Comment 2 Owen Taylor 2003-01-16 22:50:42 UTC
Any idea of what font it is using for Hebrew? 
Comment 3 Havoc Pennington 2003-01-16 22:54:11 UTC
I have the Microsoft fonts installed at home, probably if 
fonts.conf from 8.0 defines one of those to be in "Sans" then that
would be the one used. Or it's possible I changed the font from Sans 
to Andale Mono or something.

jrb could not reproduce on his non-Microsoft-fonts machine.
Comment 4 Owen Taylor 2003-01-28 23:52:30 UTC
I can't reproduce individually selecting each of the 
Windows XP Hebrew fonts. I'm afraid you're going to have
to debug this one, or at least figure out the font.
(If you look at a FT_Face structure, the filename will
be in there.)
Comment 5 Havoc Pennington 2003-01-29 02:44:57 UTC
Hmm, with Arioso I get a slightly different crash (Arabic shaper), 
don't know if this is related:

  • #0 synthesize_class_def
    at pango-ot-info.c line 192
  • #1 pango_ot_info_get_gdef
    at pango-ot-info.c line 267
  • #2 pango_ot_info_get_gsub
    at pango-ot-info.c line 282
  • #3 get_tables
    at pango-ot-info.c line 330
  • #4 pango_ot_info_find_script
    at pango-ot-info.c line 381
  • #5 get_ruleset
    at arabic-xft.c line 86
  • #6 arabic_engine_shape
    at arabic-xft.c line 156
  • #7 pango_shape
    at shape.c line 47
  • #8 process_item
    at pango-layout.c line 2572
  • #9 process_line
    at pango-layout.c line 2732
  • #10 pango_layout_check_lines
    at pango-layout.c line 3002

Comment 6 Owen Taylor 2003-03-06 21:48:25 UTC
*** Bug 107590 has been marked as a duplicate of this bug. ***
Comment 7 Owen Taylor 2003-03-06 21:54:24 UTC
The arabic-shaper crash is, I think, utterly unrelated 
(perhaps a dup ... looks familar)

Bug 107590 has a nice small reproducer for the hebrew
engine crash. (At least the back trace looks the same)

Seems to crash before it even does anything with the
font, so the particular font shouldn't matter.
Comment 8 Dov Grobgeld 2003-03-09 19:47:05 UTC
I found that that the reason for the crash is the use of lookup tables
for determining character classes and composabilities. Unfortunately
the table lookups  didn't take into consideration the "second" range
of Hebrew character sat U+F1?? and therefore there was a crash due to
lookup way beyond the array size. In the patch that I am providing
here, I solve the crashing problem. The patch still doesn't solve the
rendering issue between the F1?? charactes and punctuation mark. But
that's just a visual problem, that is less urgent.
Comment 9 Dov Grobgeld 2003-03-09 19:49:22 UTC
Created attachment 14874 [details] [review]
Fixes the crash of the Hebrew module for the U+F1?? character range.
Comment 10 Owen Taylor 2003-03-10 14:41:41 UTC
Wow, that is hacky ;-)

If you want to go ahead and commit to the pango-1-2 and
HEAD branches of Pango, that would be great.

As mentioned in comments in bug 89449, the right fix from my 
perspective is to decompose as the first step so that the
precomposed compatibility forms go through the same 
code path as the normal versions.

Comment 11 Dov Grobgeld 2003-03-12 21:06:25 UTC
The patch http://bugzilla.gnome.org/showattachment.cgi?attach_id=14874
was commited to the the HEAD and the pango-1-2 branches.
Comment 12 Owen Taylor 2003-03-13 14:48:00 UTC
Closing, since I think bug 89449 covers "doing it right"
sufficiently.

Thanks.
Comment 13 Owen Taylor 2003-05-20 12:52:35 UTC
*** Bug 113332 has been marked as a duplicate of this bug. ***