Assertion Fails at Runtime

[Kip Warner]

Binary package hint: libcairo2

cairo-ft-font.c:678: _cairo_ft_unscaled_font_set_scale: Assertion `error == 0' failed.
Aborted

This bug occurs in libcairo2 1.0.4 but has been patched already last year (http://lists.freedesktop.org/archives/cairo-bugs/2005-September/000203.html)

It can be fixed by moving libcairo 1.2.4 from Edgy to Dapper's package repository. The problem is with complex newer dependencies.

Kip

[Kip Warner (kip)]

Created an attachment (id=6788)
# FC_DEBUG=1 codeblocks > debuglog.txt

Executed codeblocks this time with...

# FC_DEBUG=1 codeblocks > debuglog.txt

[Kip Warner (kip)]

Later debugging revealed that the first FT_Set_Char_Size in
_cairo_ft_unscaled_font_set_scale was failing. I hope this helps.

Kip

[Kip Warner (kip)]

Additional debugging has revealed that the culprit font, if it's the font's
fault, is DejaVuSans.ttf

Adding the following to the end of _cairo_ft_unscaled_font_set_scale

if(error != 0){
    printf("About to blow...\n");
    printf("\"%s\"\n", unscaled->filename);
}
    assert (error == 0);

Produced the following:

About to blow...
About to blow...
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf"
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf"

Kip

[Kip Warner (kip)]

Binary package hint: libcairo2

cairo-ft-font.c:678: _cairo_ft_unscaled_font_set_scale: Assertion `error == 0' failed.
Aborted

This bug occurs in libcairo2 1.0.4 but has been patched already last year (http://lists.freedesktop.org/archives/cairo-bugs/2005-September/000203.html)

It can be fixed by moving libcairo 1.2.4 from Edgy to Dapper's package repository. The problem is with complex newer dependencies.

Kip

[Kip Warner (kip)]

http://forums.codeblocks.org/index.php?topic=3921.0

It may be that the problem may only occur on dual core systems. One other
gentleman has been having the same problem on his laptop, but not on his
desktop.

Kip

[Alex-castaing (alex-castaing)]

I have the same problem an using ubuntu dapper on an IBM T60 Dual Core

[Crzysdrs (crzysdrs)]

I have seen this issue on Gentoo Linux, Pentium 4 3.2 GHz Hyperthreaded.

[Ryan Mulder (ryanjmulder)]

I have seen this issue on Ubuntu Dapper, Pentium 4 2.8 GHz Hyperthreaded.

[DrLock (nospam-drlock)]

I am having the same problem on Pentium 4 Prescott DT, 2.8GHZ running Ubuntu AMD64

[DrLock (nospam-drlock)]

If it helps the value of error when assert fails is: 0x81, 0x88, 0x82
These appear to come from line 643: error = FT_Set_Char_Size(..)

The FreeType errors that correspond to this are:
FT_ERRORDEF_( Too_Few_Arguments,0x81, "too few arguments" )
FT_ERRORDEF_( Stack_Overflow, 0x82, "stack overflow" )
FT_ERRORDEF_( ENDF_In_Exec_Stream, 0x88, "found ENDF opcode in execution stream" )

[Freedesktop (freedesktop)]

Can someone figure out which font is causing the crash?

[Kip Warner (kip)]

(In reply to comment #10)
> Can someone figure out which font is causing the crash?

See comment #3.

Kip

[Freedesktop (freedesktop)]

(In reply to comment #11)
> (In reply to comment #10)
> > Can someone figure out which font is causing the crash?
>
> See comment #3.
>
> Kip

Ok, any specific letters that cause it?
What versions of freetype and dejavu?

[Kip Warner (kip)]

Nobody's sure. Here is the thread we have going on it over in the Code::Blocks
world. For now, Code:Blocks is totally unusable until this bug is fixed though
=(

http://forums.codeblocks.org/index.php?topic=3921

Kip

[Muecker-gwdg (muecker-gwdg)]

(In reply to comment #13)
> Nobody's sure. Here is the thread we have going on it over in the Code::Blocks
> world. For now, Code:Blocks is totally unusable until this bug is fixed though
> =(
>
> http://forums.codeblocks.org/index.php?topic=3921
>
> Kip

Uncommenting the assertion works for me.

[Kip Warner (kip)]

Do you mean commenting out the assertion? I would imagine the only thing
uncommenting an assertion could do is add another location for the process to
terminate.

If you meant commenting out the assertion, keep in mind that the problem was
not with the assert failing, but with that which was intended to not fail
before it.

Kip

[Dgorst (dgorst)]

Same problem on Gentoo 2006.1 AMD64 (Turion X2) ...

[Carl Worth (cworth)]

One thing that would really help in tracking down this bug is a minimal test
program that reproduces the bug. It's not clear to me that any cairo developer
has ever succesfully reproduced this bug, (and I know that some of them have
been using DejaVu fonts without problems for months).

-Carl

[Kip Warner (kip)]

Have you tried building and running the latest Code::Blocks under Linux on a
system with two logical processors? I would suggest this.

Kip

[Daniel Holbach (dholbach)]

Thanks for your bug report. How can I try to reproduce the error?

[Kip Warner (kip)]

Hey man,

Check out the thread we have going on libCairo:
https://bugs.freedesktop.org/show_bug.cgi?id=8104

Kip

[Sebastien Bacher (seb128)]

There is an upstream task opened, marking confirmed, the bug is known upstream

[Sebastien Bacher (seb128)]

Do you still get the issue? Could you describe a way to trigger the bug?

[Kip Warner (kip)]

I haven't had this issue in a long time, but here was what we discussed when I discovered it using CodeBlocks:

http://forums.codeblocks.org/index.php?topic=3921.0

And here is the issue noted severity CRITICAL upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=8104

Sorry I couldn't be more help.

Kip

[Sebastien Bacher (seb128)]

The upstream bug has got no recent comment though

[Kip Warner (kip)]

True. I hate to say it, but they were a rather miserable bunch to have to deal with. At least as far as those who were around in their irc channel back when I tried to explain it to them. Basically it went something like this, "there is a problem, here is what is happening, here is a stack trace, steps to reproduce, and I've even done some debugging for you and know exactly what line it is raising the exception at". The response was something like, "it works fine for everyone else, so it must be something you're doing wrong. There isn't any problem, because if there was one, we might have to do something about it". So I just left it at that and went about my business.

[Sebastien Bacher (seb128)]

Their issue is that they need those informations to work on the bug

[Kip Warner (kip)]

They have all of that information. They even know which font was the culprit and which line the signal was being raised.

[Sebastien Bacher (seb128)]

Could be useful to have a small testcase though and verify if that's still happening, there is lot of people using this font and only a small number of users who ran into the bug

[Kip Warner (kip)]

It was difficult to reproduce and we only had it happen on dual core systems. In any case, ability to reproduce isn't as important as it sounds since that is usually the method to track down the problem. But I already know the problem and exactly where the signal is raised.

[Chris Wilson (ickle)]

The final comments of this bug indicate that it is a threading issue that should have addressed by the ft-font locking introduced during the 1.3 dev cycle. The asssertion itself has been removed in favour of propagating the error, but that seems orthogonal to the underlying bug.

[Kip Warner (kip)]

Hey Chris. I think you're right that it doesn't solve the underlying problem. But at least we can avoid the segfault until we figure it out.

It also makes sense that it was an issue of multithreading since when I first discovered it, it only seemed to be reproducable on multi core machines (multi physical or just logical as in hyperthreading).

Kip

[Chris Wilson (ickle)]

(In reply to comment #20)
> Hey Chris. I think you're right that it doesn't solve the underlying problem.
> But at least we can avoid the segfault until we figure it out.

Oops, is this still current? I've not encountered anything similar since prior to the introduction of the locking, nor have any of the multi-thread stress tests hit upon a problem. If you can give me a recipe of how to reproduce this I'll investigate. Thanks.

[Kip Warner (kip)]

Not sure if it is still current. I don't recall anyone ever patching this. Reproducing was very difficult as it appeared to be a ghost in the code.

[Pedro Villavicencio (pedro)]

this was fixed upstream, thanks for reporting.

[Sebastien Bacher (seb128)]

the new version is in intrepid now