Summary: | libcairo terminating with abort | ||
---|---|---|---|
Product: | cairo | Reporter: | Kip Warner <Kip> |
Component: | general | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | critical | ||
Priority: | highest | CC: | dgorst |
Version: | 1.2.4 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | # FC_DEBUG=1 codeblocks > debuglog.txt |
Description
Kip Warner
2006-09-01 15:35:18 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.