Server browser rendering errors followed by segmentation fault.

Bug #246159 reported by Monkey on 2008-07-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Armagetron Advanced
Status tracked in Trunk
Yann Kaiser

Bug Description

This happens in 0.3 and 0.3_alpha20080706 clients but not in any 0.2.8 clients.

When the server browser comes up, there are some strange rendering errors which are usually followed by the client crashing with a "segmentation fault" error.

I am using FTGL version 2.1.3~rc5 (which is still the latest release at the time of this writing).

I have attached a screenshot. Notice how the rendering of x server and fortress cafe is messed up.

My system:
X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Slackware 12.1 Slackware Linux Project
Current Operating System: Linux slackware #2 SMP Wed Apr 30 13:41:38 CDT 2008 i686
Build Date: 30 June 2008 11:57:32PM
128MB ATI Radeon 9200 gfx card

Monkey (monkey-arma) wrote :
description: updated
wrtlprnft (wrtlprnft) wrote :

Can you try FTGL 2.1.2? That's what I'm currently using, maybe they added some kind of UTF-8 support that we accidentially enabled, because your rendering errors appear to be related to latin-1 characters.

In fact, if FTGL really added UTF-8 support that would be really sweet.

wrtlprnft (wrtlprnft) wrote :

FTGL version 2.1.3~rc5 indeed introduces UTF-8 support. I didn't have time to install it, but I committed a new revision that should tell FTGL to use latin-1 as the charset, maybe that will fix your bug.

Monkey (monkey-arma) wrote :

It still does not work - it still renders the same way and crashes.

BabyBug (babybug) wrote :

Attachment from my dupe report :x

Yann Kaiser (epsy) wrote :

I don't have FTGL 2.1.3 installed right now on this machine, but I will install it and work on it as soon as i get time, most probably this week-end.

Changed in armagetronad:
assignee: nobody → epsy
importance: Undecided → High
milestone: none → 0.3.2
status: New → Confirmed
Yann Kaiser (epsy) wrote :

#0 0xb7bf19a1 in FTCharmap::GlyphListIndex () from /usr/lib/
#1 0xb7bf4d3c in FTGlyphContainer::Glyph () from /usr/lib/
#2 0xb7bfc39f in FTFontImpl::CheckGlyph () from /usr/lib/
#3 0xb7bfd8de in FTFontImpl::Advance () from /usr/lib/
#4 0xb7bfc19c in FTFont::Advance () from /usr/lib/
#5 0x081cfa54 in rTextField::StringOutput ()
#6 0x080673a9 in operator<< <tString> ()
#7 0x080cdafa in gServerMenuItem::RenderBackground ()
#8 0x081c668c in uMenu::OnEnter ()
#9 0x080cbf66 in gServerBrowser::BrowseServers ()
#10 0x080cc13b in gServerBrowser::BrowseSpecialMaster ()
#11 0x080cc19a in gServerBrowser::BrowseMaster ()
#12 0x081c2cda in uMenu::HandleEvent ()
#13 0x081c647a in uMenu::OnEnter ()
#14 0x0809224b in net_game ()
#15 0x081c2cda in uMenu::HandleEvent ()
#16 0x081c647a in uMenu::OnEnter ()
#17 0x081c2cda in uMenu::HandleEvent ()
#18 0x081c647a in uMenu::OnEnter ()
#19 0x08096b5a in MainMenu ()
#20 0x08065b2c in main ()

seems to be caused by could-be-unicode characters messing up FTGL when calculating word and line widths(for line breaks), as suggested by the last processed string:

" Búññý"

Manuel Moos (z-man) wrote :

our utf8 support fixes this.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers