From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: When I select iso10646 encoding and then select any of 'ar pl' fonts and move mouse, X crashes. Other fonts with the same encoding doesn't seem to be a problem, nor other encodings Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21 How reproducible: Always Steps to Reproduce: 1. xfontsel select iso10646 encoding 2. select any of the 'ar pl' font 3. move mouse Actual Results: X crashed Expected Results: X not crashing, font switched Additional info: This happend on my desktop as well as notebook with same configuration
This bug seems to be similar to #121403 - non-XFT builds of Mozilla can also crash X server when viewing pages with unrecognized unicode characters (description from this bug report â https://bugs.freedesktop.org/show_bug.cgi?id=659 ). Using xfontsel you can always reproduce this bug without any hassle :)
Trace of this crash: 0x00208662 in DrawTETextScanlineGeneric (base=0x825c1a8, glyphp=0x825e2b0, line=0, width=340, glyphwidth=17) at xaaTEGlyph.c:556 556 CARD32 bits = (*glyphp)[line]; The crash happens because *glyphp is 0 at this point #0 0x00208662 in DrawTETextScanlineGeneric (base=0x825c1a8, glyphp=0x825e2b0, line=0, width=340, glyphwidth=17) at xaaTEGlyph.c:556 #1 0x002081d6 in XAATEGlyphRendererScanlineLSBFirst (pScrn=0x8221a88, x=67, y=142, w=340, h=16, skipleft=0, startline=1, glyphs=0x825e2b0, glyphWidth=17, fg=0, bg=-1, rop=3, planemask=4294967295) at xaaTEGlyph.c:406 #2 0x001e73a4 in XAAGlyphBltTEColorExpansion (pScrn=0x8221a88, xInit=67, yInit=157, font=0x82aa7d0, fg=0, bg=-1, rop=3, planemask=4294967295, cclip=0x82c3a5c, nglyph=20, gBase=0x0, ppci=0x825a0d0) at xaaTEText.c:28 #3 0x001e74f5 in XAAPolyText8TEColorExpansion (pDraw=0x82c3a30, pGC=0x82c3ec8, x=66, y=88, count=20, chars=0x82b378e ("<chars that screws vte>") at xaaTEText.c:66 #4 0x08151b30 in cwPolyText8 (pDst=0x82c3a30, pGC=0x82c3ec8, x=66, y=88, count=20, chars=0x82b378e at cw_ops.c:362 #5 0x0814be09 in damagePolyText8 (pDrawable=0x82c3a30, pGC=0x82c3ec8, x=66, y=88, count=20, chars=0x82b378e at damage.c:1355 #6 0x080d52d5 in doPolyText (client=0x82a7940, c=0xbffff260) at dixfonts.c:1403 #7 0x080d567d in PolyText (client=0x82a7940, pDraw=0x0, pGC=0x0, pElt=0x0, endReq=0x0, xorg=0, yorg=0, reqType=136700592, did=0) at dixfonts.c:1484 #8 0x080ba0ae in ProcPolyText (client=0x82a7940) at dispatch.c:2372 #9 0x080bc71b in Dispatch () at dispatch.c:455 #10 0x080c7737 in main (argc=3, argv=0xbffff804, envp=0xbffff814) at main.c:442
The offending requests seems to be these: ............REQUEST: OpenFont font-id: FNT 0020005a name: "-*-ar pl kaitim big5-*-*-*-*-*-*-*-*-*-*-*-*" [...] ............REQUEST: CreateGC graphic-context-id: GXC 0020005b drawable: DWB 00200052 value-mask: background | font | graphics-exposures value-list: background: 00ffffff font: FNT 0020005a graphics-exposures: False [...] ............REQUEST: PolyText8 drawable: DWB 00200052 gc: GXC 0020005b x: 66 y: 88 items: delta: 0 text item 8 string: "\340\346\347\353\356\360\361\363\371\375\300\306\307\313\316\320\321\323\331\335" delta: 108
Bug does not happen with 'Option "NoAccel"'.
Created attachment 111601 [details] A minimal crasher
It looks like the default glyph for the fonts has NULL bits somehow.
Created attachment 111644 [details] A patch
Created attachment 111645 [details] A patch that has a chance of working beyond simple tests
*** Bug 121403 has been marked as a duplicate of this bug. ***