Reporting a playtest

For topics that do not fit in another sub-forum.

Moderators: Oberlus, Oberlus

User avatar
Release Manager, Design
Posts: 5354
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Reporting a playtest

#16 Post by Vezzra » Sun Feb 19, 2012 12:57 pm

Geoff the Medio wrote:If you can isolate the specific line and/or conditions for when it's happening on by inserting debug output or using breakpoints, I might be able to fix it
It took some effort, but I was able to track down the issue at least to some point. The problem occurs in the "Render" method of the CUILinkTextMultiEdit control of the Pedia window. Well, actually several levels deeper, in GG::Font::HandleTag, where a call to "assert" fails (when trying to render the contents of the edit control). This btw is also the reason why the logs didn't contain any useful info, because on the GG layer error messages are dumped to stderr, not to Logger().errorStream of course. Which leads me to a side question: Is there a way to redirect stdout and stderr to the respective logger streams? This would allow to catch error messages which otherwise go unnoticed.

What was kind of baffling with this issue is that it didn't seem to occur consistently. First of all, I was only able to reproduce the crashes reported by Komori when I tried to scroll around in the Pedia window on certain pages. I never got crashes when I just clicked on links. Second, the crashes never occured when I resized the Pedia window to a size large enough to display the entire content of these certain pages which would trigger crashes when I have to scroll through exactly the same contents when the window is smaller.

The code section with the failing assertion is:

Code: Select all

    } else if (tag->tag_name == "rgba") {
        if (tag->close_tag) {
            if (render_state.colors.empty())
        } else {
The error message thrown is:

Code: Select all

Assertion failed: (!render_state.colors.empty()), function HandleTag, file /Users/[...]/GG/src/Font.cpp, line 1471.
Abort trap
From what I was able to piece together (with my very limited knowledge of the FO code, not to speak of GiGi), apparently when rendering the contents of this edit control a rgba close tag is encountered for which no corresponding open tag exists. I was able to confirm my hypothesis with debug code and output I inserted. However, as this error condition only occurs under very specific circumstances, and not even consistently with the exact same content, but apparently dependent on how the text flows in the edit control, I don't think the text itself is broken - there actually isn't a close tag that shouldn't be there (otherwise this error would occur regardless of the size of the Pedia window and how the text flows). I suspect that there is something amiss with the way the text lines are wrapped, and somehow one close tag is handled twice. This seems the most fitting explanation, at least to me.

However, there still remains the big question why this issue only shows up on OSX. Judging from what I found out so far, this should be platform independent - unless the assert function behaves differently on the various platforms. Is it supposed to terminate the application? Or should it just abort current event processing? As I'm unable to build FO on my windows machines, I can't run my tests on windows to cross-check the results.

To reproduce the error I followed this procedure: Setting up a new game with 500 systems, starlane frequency, monsters and natives set to high, 12 AI's and using Super Testers as race pick. After the game has started I don't do anything, just open the Pedia, go to "Planets" and scroll down the list. Crashes the game after I've scrolled just a few lines. Important: to see any error messages thrown by GiGi, the FreeOrion client executable has to be launched from the terminal (otherwise the output to stdout and stderr goes to limbo).

I hope I was at least able to give some starters to track down the problem... do you think you can work from there?
though by then you're probably most of the way to fixing it yourself.
That's what I thought too, but after I've come so far, I've to admit that I'm stuck at the moment. Beside the general observation that the text flowing somehow seems to break color tag handling I have no idea what exactly is going wrong here. If an idea decides to strike me, I'll give it another try of course ;)

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12689
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Reporting a playtest

#17 Post by Geoff the Medio » Sun Feb 19, 2012 6:58 pm

The Windows builds have NDEBUG defined, which I think is the preprocessor define that disables asserts, which would probably be why this issue doesn't appear on Windows builds.

It sounds like a GG internal error with, I'd guess, colour tags in the text itself that surround text that is wrapped over lines in multiline Edit control.

You might want to add a GG bug report about it to ensure tzlaine sees it: ... unc=browse

Post Reply