Created attachment 6788 [details]
# FC_DEBUG=1 codeblocks > debuglog.txt

Executed codeblocks this time with...

# FC_DEBUG=1 codeblocks > debuglog.txt

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

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

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

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

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

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

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

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" )

Can someone figure out which font is causing the crash?

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

See comment #3.

Kip

(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?

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

(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.

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

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

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

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

Kip

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.

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

(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.

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.