registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #15061
[Bug 58519] Re: Assertion Fails at Runtime
Launchpad has imported 23 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=8104.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2006-09-01T15:35:18+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/0
------------------------------------------------------------------------
On 2006-09-01T15:43:17+00:00 Kip Warner wrote:
Created an attachment (id=6788)
# FC_DEBUG=1 codeblocks > debuglog.txt
Executed codeblocks this time with...
# FC_DEBUG=1 codeblocks > debuglog.txt
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/1
------------------------------------------------------------------------
On 2006-09-01T16:30:44+00:00 Kip Warner wrote:
Later debugging revealed that the first FT_Set_Char_Size in
_cairo_ft_unscaled_font_set_scale was failing. I hope this helps.
Kip
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/2
------------------------------------------------------------------------
On 2006-09-01T18:57:20+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/3
------------------------------------------------------------------------
On 2006-09-05T09:21:35+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/5
------------------------------------------------------------------------
On 2006-09-11T04:36:00+00:00 Alex-castaing wrote:
I have the same problem an using ubuntu dapper on an IBM T60 Dual Core
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/6
------------------------------------------------------------------------
On 2006-09-12T00:54:03+00:00 Crzysdrs wrote:
I have seen this issue on Gentoo Linux, Pentium 4 3.2 GHz Hyperthreaded.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/7
------------------------------------------------------------------------
On 2006-09-12T05:30:45+00:00 Ryan Mulder wrote:
I have seen this issue on Ubuntu Dapper, Pentium 4 2.8 GHz
Hyperthreaded.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/8
------------------------------------------------------------------------
On 2006-09-12T12:58:28+00:00 DrLock wrote:
I am having the same problem on Pentium 4 Prescott DT, 2.8GHZ running
Ubuntu AMD64
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/9
------------------------------------------------------------------------
On 2006-09-12T14:06:05+00:00 DrLock wrote:
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" )
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/10
------------------------------------------------------------------------
On 2006-09-12T14:33:07+00:00 Freedesktop wrote:
Can someone figure out which font is causing the crash?
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/11
------------------------------------------------------------------------
On 2006-09-12T20:18:20+00:00 Kip Warner wrote:
(In reply to comment #10)
> Can someone figure out which font is causing the crash?
See comment #3.
Kip
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/12
------------------------------------------------------------------------
On 2006-09-13T08:13:46+00:00 Freedesktop wrote:
(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?
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/13
------------------------------------------------------------------------
On 2006-09-13T19:14:20+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/14
------------------------------------------------------------------------
On 2006-09-15T08:34:25+00:00 Muecker-gwdg wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/15
------------------------------------------------------------------------
On 2006-09-16T01:24:36+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/16
------------------------------------------------------------------------
On 2006-10-03T22:16:57+00:00 Dgorst wrote:
Same problem on Gentoo 2006.1 AMD64 (Turion X2) ...
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/17
------------------------------------------------------------------------
On 2006-10-04T11:12:17+00:00 Carl Worth wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/18
------------------------------------------------------------------------
On 2006-10-04T20:26:07+00:00 Kip Warner wrote:
Have you tried building and running the latest Code::Blocks under Linux on a
system with two logical processors? I would suggest this.
Kip
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/19
------------------------------------------------------------------------
On 2008-10-10T07:14:05+00:00 Chris Wilson wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/31
------------------------------------------------------------------------
On 2008-10-10T10:21:11+00:00 Kip Warner wrote:
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
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/32
------------------------------------------------------------------------
On 2008-10-10T10:31:06+00:00 Chris Wilson wrote:
(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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/33
------------------------------------------------------------------------
On 2008-10-10T23:58:42+00:00 Kip Warner wrote:
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.
Reply at: https://bugs.launchpad.net/libcairo/+bug/58519/comments/34
** Changed in: libcairo
Importance: Unknown => Critical
--
Assertion Fails at Runtime
https://bugs.launchpad.net/bugs/58519
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for libcairo.
