Apache OpenOffice (AOO) Bugzilla – Issue 2423
selection of webdings font causes hang in linux
Last modified: 2002-05-16 10:21:40 UTC
When I select webdings.ttf font the application hangs with consuming as much CPU as available. This applies to selection of font in font preview (listbox in toolbar) and to the selection of this font in context-sensitive menu if some text is selected already. The same is true if you select the font and try to type with it. No problems so far with other ttf fonts. My configuration: Linux/Debian Woody, XFree 4.1. Application is run over the network (xserver and soffice are in different computers) with ttf fonts shared by NFS.
On http://www.debian.org/releases/testing you can read that "Woody" is still under development. Please have a look there and assure that you are "up to date" with your system to avoid misleading findings in applications where the system is to blame. Try this: Select the font webdings.ttf using the program xfontsel. If xfontsel crashes then it is very likely that this font is broken. In this case every X application which tries to use this font will crash. Please verify and comment. Thank you.
my woody system should be up to date (I did update this morning). The same issue was before update too. I've tried to run xfontsel, xterm and even emacs21 with the specified font --- no problem, it shows it nicely without any hang. The problem remains if soffice and XFree server are running on the same computer (woody).
I probably have the same problem on Redhat Linux 7.1. But the writer hangs just when it tries to render the example characters in the combobox. And I don't run the soffice over the network. See also Issue 2143.
Reassigned to Ulf.
and issue 2417
Reassigned to Herbert Duerr.
Looks related 2143. Can you please do: strace -f 2>&1 soffice | tee strace.out Make it crash, then do fgrep open strace.out | tail and copy the results here? Also a dozen lines after the last open() in strace.out would be very interesting.
Created attachment 832 [details] strace and gdb backtrace
command `strace -f 2>&1 soffice | tee strace.out ` resulted in soffice starting up so slowly (I waited more than 10min without any real change) that I've decided to start without strace, attach strace later to all pids and analyze the data. Additionally I've attached gdb to the process which was consuming CPU and added its backtrace. The attachment is sent already... If you still want me to run `strace -f 2>&1 soffice | tee strace.out ` then please tell me --- I will let it running this night...
Thank you for the great input. I wouldn't have expected a crash there. No need to do the other strace run. What exact version of 641 are you using 641A, B or C? Do you know how to compile a module of OO? If yes it would be great to use a version of VCL with debug info. If no I can build one for you.
I am not sure about version, I guess it is 641b. Filename was install641_linux_intel.tar.gz, MD5 f7282dedb4571a60f47d1ca8df3f1dbb I haven't compiled the module before... So, if you have it compiled with debug info, I can download it. The network connection that I am using is relatively fast.
I tried to upload a libvcl with debug info but this failed. It is too big. Can I sent you the 1.6MB file per email?
no problem, should be OK.
it seems that the bug is triggered only if the fonts is antialiased. namely, with the library you sent the font is displayed without antialias and the bug is not showing up (I've selected webdings font and the program didn't hang, but didn't displayed anything too). it's funny, but antialias setting is ignored by the version of the library you've sent to me. when I tried to select webdings font with the version of the lib I had before (original) and with antialias turned off, the program didn't hanged too. thus, it seems that something is wrong with antialias code, probably...
AA should work as before. Can you please try the attachment xrinfo.e below and send the result?
Created attachment 834 [details] tool to get info XRENDER on -display :0
this tool wasn't working on remote display. on local display it worked: Render version 0.1 PFmt[1] t=1, d=8, r=0 0x00, g=0 0x00, b=0 0x00, a=0 0xFF PFmt[2] t=1, d=24, r=16 0xFF, g=8 0xFF, b=0 0xFF, a=0 0x00 PFmt[3] t=1, d=16, r=11 0x1F, g=5 0x3F, b=0 0x1F, a=0 0x00 PFmt[4] t=1, d=15, r=10 0x1F, g=5 0x1F, b=0 0x1F, a=0 0x00 PFmt[5] t=1, d=16, r=10 0x1F, g=5 0x1F, b=0 0x1F, a=15 0x01 PFmt[6] t=1, d=1, r=0 0x00, g=0 0x00, b=0 0x00, a=0 0x01 Renderinfo done antialiasing wasn't working on local display too. maybe there were some changes in soffice code that make such usage of your library incompatible? btw, if antialiasing is turned off, things printed by webdings font are invisible (chars are empty). if I use this font with emacs or xterm, it displays the chars as it should. one more puzzle... do you have debug version of the office? is it possible to download this beast? or should I try to build current CVS version with debugging enabled?
I've compiled debug version of vcl. The endless loop was as follows: Glyph X11GlyphPeer::GetGlyphId( ServerFont& rServerFont, int nGlyphIndex ) { Glyph aGlyphId; GlyphData& rGlyphData = rServerFont.GetGlyphData( nGlyphIndex ); if( rGlyphData.GetExtInfo() == XRENDER_KIND ) aGlyphId = (Glyph)rGlyphData.GetExtPointer(); else { // prepare GlyphInfo and Bitmap if( !rServerFont.GetGlyphBitmap8( nGlyphIndex, maRawBitmap ) ) return GetGlyphId( rServerFont, 0 ); <------------- *** THIS WAS CALLED ALWAYS *** [...] it seems that with this font rServerFont.GetGlyphBitmap8( nGlyphIndex, maRawBitmap ) was always false.
Great analysis!!! This means the font does not contain a "notdef" glyph, which violates the truetype specification. The hang shouldn't happen though and the issue was fixed in vcl/unx/source/gdi/gcach_xpeer.cxx >= 1.19 Do you have CVS access or do you want me to sent the fixed file?
indeed the new .cxx and .hxx file inserted into the 641b code fixed the bug! however, I had to enable antialiasing explicitly in the code using some forceantialias variable. as the result, the antialiased characters were quite ugly, with antialiasing done by colores (I guess it is designed for laptops?). why it is so, I don't know...
I'm glad the original bug got fixed. If you don't mind we should attack the other problems too, since you seem to have an interesting setup. Did you enable bForcedAA? What is the bit depth of your display? If it is not 24bit or 32bit this explains the color seam, since the forced AA = software antialiasing is not yet implemented for 15 or 16bit displays. Somehow the variable mbUsingXRender could not be enabled. Do you happen to have XINERAMA on the X11 server? You can find this out by doing xdpyinfo | fgrep XINERAMA
I've studied the differences between current and 641b versions. It turns out that mbUsingXRender is not set to true if mpGlyphFormat = (*pXRenderFindFormat)( mpDisplay,PictFormatAlphaMask|PictFormatDepth, &aPictFormat, 1 ); is used. If I change it to the older version, mpGlyphFormat = (*pXRenderFindFormat)( mpDisplay, 0, &aPictFormat, 1 ); (difference in the second argument), everything is working nicely --- antialias is enabled (mbUsingXRender=true) and the quality is nice.
here is the mail I've sent yesterday directly to hdu@... (just to keep the log) Soory for sending this mail directly to you --- I am at home and its harder to log in into openoffice.org site ... Indeed I used mbForcedAA = true; in the code. The depth is 16, no XINERAMA. In 641b everything was fine --- antialiased worked very nicely.
That render antialiasing works better for you when the second argument of XRenderFindFormat is zero is difficult to understand, because xrinfo told > PFmt[1] t=1, d=8, r=0 0x00, g=0 0x00, b=0 0x00, a=0 0xFF I.e. there is an 8bit PictFormatDepth and a 0xFF FormatAlphaMask, so this PictFormat should be found. I'll have a look at the history of XRENDER what happened. By the way, what is your exact version of XFree?
its up-to-date woody. same for local and remote displays --- antialias is disabled in new version. xdpyinfo : name of display: fiesta.ioc.ee: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 0x1e0000e, revert to Parent number of extensions: 28 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X3D-PEX XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XIE XInputExtension XTEST XVideo default screen number: 0 number of screens: 1
almost forgot: in new code mpGlyphFormat == NULL.
moving from SW to GSL bugs
Pease change the line to mpGlyphFormat = (*pXRenderFindFormat)( mpDisplay,PictFormatAlphaMask|PictFormatDepth, &aPictFormat, 0 ); Notice the last parameter changed from 1 to zero.
yes, it works!
Great! Thanks alot for your outstanding cooperation. Ready to close the bug?
sure! close it. thank you very much for fixing these bugs!
Closing.
closing.