Apache OpenOffice (AOO) Bugzilla – Issue 7678
openoffice crashes with these fonts
Last modified: 2013-08-07 14:38:26 UTC
If I use the font Burgundian (bu_____.pfb) and the font Sumdumgoi (sumdumgo.pfb) from the sharefont package in Debian, the application crashes after trying to select the fonts in the font list. ------------------------------------------------------------------ xset -q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 auto repeat delay: 660 repeat rate: 25 auto repeating keys: 00ffffffdffffbbf fa9fffffffdff5ff ffffffffffffffff ffffffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: yes allow exposures: yes timeout: 0 cycle: 600 Colors: default colormap: 0x20 BlackPixel: 0 WhitePixel: 16777215 Font Path: /home/martin/.kde/share/fonts/override,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/home/martin/.kde/share/fonts Bug Mode: compatibility mode is disabled DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 2400 DPMS is Disabled Font cache: hi-mark (KB): 1024 low-mark (KB): 768 balance (%): 70 ------------------------------------------------------------------------- xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40100001 XFree86 version: 4.1.0.1 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x1c000b3, revert to PointerRoot number of extensions: 31 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD NV-CONTROL NV-GLX NVIDIA-GLX RECORD RENDER SECURITY SHAPE SYNC TOG-CUP X3D-PEX XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XIE XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1024x768 pixels (260x195 millimeters) resolution: 100x100 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x60 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 32x32 current input event mask: 0xd84031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 8 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x22 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x27 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x28 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits
Created attachment 2822 [details] Metrics file for the font Sumdumgoi
Created attachment 2823 [details] Font Sumdumgoi
Created attachment 2824 [details] Font Burgundian
Can you give us a stack dump of the crash happening in OOo1.1beta2? See http://kegel.com/openoffice/#dump (or wait for OOo1.1rc1, which will have a built-in crash logger) Thanks!
I'm adding the "oooqa" keyword & setting the priority to P1 from P3. I see that the version is 1.0.3. Would you be willing to upgrade to see if a new version works better?
Reassigned to Ulf.
No reporter-activity for months No votes No other one who confirmed the problem I think we should close that issue as WFM, if someone still sees the problem, the issue can be reopened If I will not see any further action as votes, attachments or confirmations in this issue, I will have to close this issue 2003-08-31 as WFM. Rainer
Created attachment 8014 [details] font metrics for Burgundian
Sumdumgoi does not crash OOo in current inhouse version (srx645_m14s1.8665), but Burgundian does. Test: formatted a dummy text with the font. Created afm file for Burgundian with pf2afm (GNU Ghostscript 6.51). Attaching bu_____.afm file for easier reproduction. @ RainerBielefeld: pls. be patient or better reproduce the issue and confirm it. Thx. @ Eugene T.S. Wong: you see promoting the Prio does not help. Only reproducing and confirming an issue *does* matter. BTW: P1 is inappropriate. Crashes are P2. P1 is for severe damage caused by OOo. Example: OOo would remove user's home directory on deinstall, or the like. Thanks for contributing OOo anyway, guys!
pl->us: P1 was perfectly right when the issue was created ;-)
pl->hdu: no crash in 645m14; but it seems that freetype doesn't like to render that font (please note the less than perfect behaviour in normal as well as in online view).
pl->hdu: i have to correct myself; burgundian does crash as Ulf reported. It does so somewhere inside FreetypeServerFont
Crash in Freetype: #0 in ps2_hints_apply () #1 in ps3_hints_apply () #2 in RepadBitmap () #3 in gray_raster_render () #4 in gray_raster_render () I'll look if the the crash in the FT lib is low hanging fruit...
Freetype's demo applications font checker FTLINT also doesn't like these fonts: "ftlint 20 bu______.pfb" results in a Segmentation fault at glyph 29 (probably due to memory overwrite in t1_decoder_parse_charstrings() "ftline 20 sumdumgo.pfb" tells us that glyphs 28 and 54 fail The two solutions are: - fixing the fonts - make freetype's type1 hinter handle problematic fonts more gracefully
HDU->US: ok to close?
us->hdu: could you pls. submit a bug against FreeType. A crash is always unpleasant from user's perspective. And a solid freetype seems to be desireable for any application, nut just OOo. Furthermore, I am convinced that as long as I live there will be broken fonts gathering around :-( @submitter: would you pls. log a bug against debian to not include this broken font? Thanks, a lot.
Just an idea, but if OpenOffice crashes when using bad/corrupted fonts, shouldnt we at least make OpenOffice handle this gracefully ? The fact that it's the fault of the font and not of OpenOffice wont matter a bit to the average end-user. For example, stop OpenOffice from loading the font if it does not like it and display an error message for the user instead of just dumping core ? Just my 2$...
I agree that OOo shouldn't crash if a library we are based upon like glibc or libfreetype crash or when the OS dies or when RAM got bad. Unfortunately this is much easier said than done. Not using fonts that crash freetype is also difficult, because it is not known in advance which fonts these would be and it is extremely dependend on the version and options of the system freetype. If every app that uses the font through the same libfreetype crashes too it is best to remove the font or to upgrade to a freetype version that doesn't have the problem with the font. Freetype version 2.1.5 doesn't crash on Burgundian anymore.
.
Works for me when using freetype 2.1.5
Closing.