Bug 8104 - libcairo terminating with abort
libcairo terminating with abort
Status: RESOLVED FIXED
Product: cairo
Classification: Unclassified
Component: general
1.2.4
x86 (IA32) Linux (All)
: highest critical
Assigned To: Carl Worth
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-01 15:35 UTC by Kip Warner
Modified: 2008-10-10 23:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
# FC_DEBUG=1 codeblocks > debuglog.txt (11.36 KB, application/x-gzip)
2006-09-01 15:43 UTC, Kip Warner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kip Warner 2006-09-01 15:35:18 UTC
I have compiled and installed libcairo 1.2.4 from source. I have verified that 
the host application, Code::Blocks, is using the library with...

kip@kip-laptop:~$ ldd /usr/local/bin/codeblocks | grep -i cairo
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6ef1000)
        libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0xb6e01000)

Executing codeblocks from gdb gives me...

(gdb) run
Starting program: /usr/local/bin/codeblocks
[Thread debugging using libthread_db enabled]
[New Thread -1229293888 (LWP 2548)]
[New Thread -1244337232 (LWP 2683)]
[New Thread -1252729936 (LWP 2684)]
[New Thread -1261122640 (LWP 2685)]
[New Thread -1269515344 (LWP 2686)]
[New Thread -1280705616 (LWP 2687)]
[New Thread -1297544272 (LWP 2694)]
codeblocks: cairo-ft-font.c:683: _cairo_ft_unscaled_font_set_scale: Assertion 
`error == 0' failed.
codeblocks: cairo-ft-font.c:683: _cairo_ft_unscaled_font_set_scale: Assertion 
`error == 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1297544272 (LWP 2694)]
0xffffe410 in __kernel_vsyscall ()


The full backtrace is as follows:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb73519a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb73532b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb734af51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0xb6ebd895 in _cairo_ft_unscaled_font_set_scale (unscaled=0x8a2bf38,
    scale=<value optimized out>) at cairo-ft-font.c:683
#5  0xb6ebf102 in cairo_ft_scaled_font_lock_face (abstract_font=0x830a638)
    at cairo-ft-font.c:2426
#6  0xb6f91260 in pango_cairo_fc_font_get_type ()
   from /usr/lib/libpangocairo-1.0.so.0
#7  0xb6c183cc in pango_fc_font_lock_face () from /usr/lib/libpangoft2-1.0.so.0
#8  0xb6a8e018 in ?? () from /usr/lib/pango/1.5.0/modules/pango-basic-fc.so
#9  0x0830a800 in ?? ()
#10 0x00000430 in ?? ()
#11 0xb7455320 in __malloc_initialize_hook () from /lib/tls/i686/cmov/libc.so.6
#12 0xb2a8fde0 in ?? ()
#13 0xb74477ed in in6addr_any () from /lib/tls/i686/cmov/libc.so.6
#14 0xb6d6d234 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0xb2a8fdd8 in ?? ()
#16 0xb7455358 in __malloc_initialize_hook () from /lib/tls/i686/cmov/libc.so.6
#17 0x081135e0 in ?? ()
#18 0x00000008 in ?? ()
#19 0xb738ba64 in malloc_usable_size () from /lib/tls/i686/cmov/libc.so.6
---Type <return> to continue, or q <return> to quit---
#20 0xb6f0cfb3 in pango_engine_shape_get_type ()
   from /usr/lib/libpango-1.0.so.0
#21 0xb6f1c2b4 in pango_shape () from /usr/lib/libpango-1.0.so.0
#22 0xb6f0fe6f in pango_layout_line_index_to_x ()
   from /usr/lib/libpango-1.0.so.0
#23 0xb6f12fbb in pango_layout_iter_get_char_extents ()
   from /usr/lib/libpango-1.0.so.0
#24 0xb6f13515 in pango_layout_iter_get_char_extents ()
   from /usr/lib/libpango-1.0.so.0
#25 0xb6f13e6c in pango_layout_iter_get_char_extents ()
   from /usr/lib/libpango-1.0.so.0
#26 0xb6f14cfa in pango_layout_get_pixel_size ()
   from /usr/lib/libpango-1.0.so.0
#27 0xb77ae4c9 in wxWindowDC::GetCharHeight ()
   from /usr/lib/libwx_gtk2u_core-2.6.so.0
#28 0xb78e9462 in wxGenericTreeCtrl::CalculateLineHeight ()
   from /usr/lib/libwx_gtk2u_core-2.6.so.0
#29 0xb78e96d1 in wxGenericTreeCtrl::SetImageList ()
   from /usr/lib/libwx_gtk2u_core-2.6.so.0
#30 0xb3adbf62 in ClassBrowserBuilderThread::BuildTree (this=0x8640f88)
    at classbrowserbuilderthread.cpp:97
#31 0xb3adc173 in ClassBrowserBuilderThread::Entry (this=0x8640f88)
    at classbrowserbuilderthread.cpp:85
---Type <return> to continue, or q <return> to quit---
#32 0xb7632bf0 in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.6.so.0
#33 0xb7632c63 in wxPthreadStart () from /usr/lib/libwx_baseu-2.6.so.0
#34 0xb7562341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#35 0xb73f24ee in clone () from /lib/tls/i686/cmov/libc.so.6
Comment 1 Kip Warner 2006-09-01 15:43:17 UTC
Created attachment 6788 [details]
# FC_DEBUG=1 codeblocks > debuglog.txt

Executed codeblocks this time with...

# FC_DEBUG=1 codeblocks > debuglog.txt
Comment 2 Kip Warner 2006-09-01 16:30:44 UTC
Later debugging revealed that the first FT_Set_Char_Size in 
_cairo_ft_unscaled_font_set_scale was failing. I hope this helps.

Kip
Comment 3 Kip Warner 2006-09-01 18:57:20 UTC
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
Comment 4 Kip Warner 2006-09-05 09:21:35 UTC
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
Comment 5 alex.castaing 2006-09-11 04:36:00 UTC
I have the same problem an using ubuntu dapper on an IBM T60 Dual Core
Comment 6 Mitch 2006-09-12 00:54:03 UTC
I have seen this issue on Gentoo Linux, Pentium 4 3.2 GHz Hyperthreaded.
Comment 7 Ryan Mulder 2006-09-12 05:30:45 UTC
I have seen this issue on Ubuntu Dapper, Pentium 4 2.8 GHz Hyperthreaded.
Comment 8 Daniel 2006-09-12 12:58:28 UTC
I am having the same problem on Pentium 4 Prescott DT, 2.8GHZ running Ubuntu AMD64
Comment 9 Daniel 2006-09-12 14:06:05 UTC
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" )
Comment 10 Behdad Esfahbod 2006-09-12 14:33:07 UTC
Can someone figure out which font is causing the crash?
Comment 11 Kip Warner 2006-09-12 20:18:20 UTC
(In reply to comment #10)
> Can someone figure out which font is causing the crash?

See comment #3.

Kip
Comment 12 Behdad Esfahbod 2006-09-13 08:13:46 UTC
(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?
Comment 13 Kip Warner 2006-09-13 19:14:20 UTC
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
Comment 14 Martin Uecker 2006-09-15 08:34:25 UTC
(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.
Comment 15 Kip Warner 2006-09-16 01:24:36 UTC
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
Comment 16 David Gorst 2006-10-03 22:16:57 UTC
Same problem on Gentoo 2006.1 AMD64 (Turion X2) ...
Comment 17 Carl Worth 2006-10-04 11:12:17 UTC
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
Comment 18 Kip Warner 2006-10-04 20:26:07 UTC
Have you tried building and running the latest Code::Blocks under Linux on a 
system with two logical processors? I would suggest this.

Kip
Comment 19 Chris Wilson 2008-10-10 07:14:05 UTC
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.
Comment 20 Kip Warner 2008-10-10 10:21:11 UTC
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
Comment 21 Chris Wilson 2008-10-10 10:31:06 UTC
(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.
Comment 22 Kip Warner 2008-10-10 23:58:42 UTC
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.