Author Topic: Constant Random Crashing (Read 28756 times)

kip · « **on:** August 27, 2006, 10:01:22 pm »

Hey guys,

I am using the latest svn revision 2914 and I am still getting regular random crashes. When I run from console, I catch its output before aborting...

codeblocks: /build/buildd/libcairo-1.2.2/src/cairo-ft-font.c:681: _cairo_ft_unscaled_font_set_scale: Assertion `error == 0' failed.
Aborted

I was using the latest version of libcairo2 (1.2.2) out of Ubuntu's Edgy and still to no avail.

It is very difficult to get any work done with gedit. Any help would be appreciated.

Kip

Phatency · « **Reply #1 on:** August 27, 2006, 11:41:25 pm »

Reproducion steps provided by Encryptor in thread http://forums.codeblocks.org/index.php?topic=3911.msg30877#msg30877

Quote from: Encryptor on August 27, 2006, 08:06:57 pm

6Symbols browser - the most annoying thing in C::B.
A
It wasn't wide enough and I tried to resize it. C::B crashed.
This is the output from C::B:

Steps to reproduce
1. Open C::B
2. Go to File-> New -> Project
3. Choose Console Application
4. Complete the Wizard
5. In the Management window, double click on Sources->main.cpp
6. Click once in the editor window
7. Grab the separator that splits the editor from the symbols browser. Drag 5 cm left. Sometimes it crashes after the first drag and drop. If it didnt crash, drag the separator left one more time. It will crash with the above error message printed in the console.
If there is no project opened, moving the separator did not crash Code Blocks. Most of the times, you dont even have to open main.cpp and click in the window. Just create a new Console project and try to resize the Symbols browser. I always get the same error.
I even got this error when double-clicking on main.cpp, but I couldn't reproduce it.
On a different occasion, while editing the text and then resizing the Symbold Browser, I got this error:

Code
(codeblocks:4439): GLib-CRITICAL **: g_queue_push_head_link: assertion `link->next == NULL' failed
     codeblocks: cairo-ft-font.c:678: _cairo_ft_unscaled_font_set_scale: Assertion `error == 0' failed.
     Aborted
However, I couldn't reproduce this either.

kip · « **Reply #2 on:** August 27, 2006, 11:52:36 pm »

It is annoying the hell out of me. What is really scary is that so many people have pointed this out on the forum and the usual response is that it is a problem with libcairo and that it was fixed an eon ago. Everyone is using whatever version of libcairo is most readily available to them through their package manager (I am on Linux). Only Edgy repository for Ubuntu has the latest libcairo and even that one did nothing any different.

Kip

mandrav · « **Reply #3 on:** August 28, 2006, 12:10:18 am »

Quote from: kip on August 27, 2006, 11:52:36 pm

It is annoying the hell out of me. What is really scary is that so many people have pointed this out on the forum and the usual response is that it is a problem with libcairo and that it was fixed an eon ago.

No one said that. As a matter of fact, I don't have any of these problems in either Ubuntu 5.10 (32bit) or Ubuntu 6.06 (64bit). And no, I haven't touched libcairo: whatever comes with the distro.

Some people report having this problem, others don't have it at all. Although it's not a C::B problem per-se, we 'd love to fix it but it's darn hard to even try since we can't reproduce it. At least no one in the team can, to my knowledge...

kip · « **Reply #4 on:** August 28, 2006, 12:27:57 am »

http://forums.codeblocks.org/index.php?topic=3364.msg27925#msg27925

http://forums.codeblocks.org/index.php?topic=3738.msg29472#msg29472

I have compiled with --enable-contrib and running a backtrace from gdb after it crashes with the aforementioned failed assert...

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb73219a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb73232b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb731af51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0xb6e9fa05 in cairo_pattern_get_extend () from /usr/lib/libcairo.so.2
#5 0xb6ea12ce in cairo_ft_scaled_font_lock_face () from /usr/lib/libcairo.so.2
#6 0xb6f61260 in pango_cairo_fc_font_get_type ()
from /usr/lib/libpangocairo-1.0.so.0
#7 0xb6c003cc in pango_fc_font_lock_face () from /usr/lib/libpangoft2-1.0.so.0
#8 0xb6c0578b in pango_ot_buffer_output () from /usr/lib/libpangoft2-1.0.so.0
#9 0xb6a760fb in ?? () from /usr/lib/pango/1.5.0/modules/pango-basic-fc.so
#10 0x08a81510 in ?? ()
#11 0x08b6d190 in ?? ()
#12 0x00000000 in ?? ()

Kip

mandrav · « **Reply #5 on:** August 28, 2006, 12:38:49 am »

Quote from: kip on August 28, 2006, 12:27:57 am

http://forums.codeblocks.org/index.php?topic=3364.msg27925#msg27925

http://forums.codeblocks.org/index.php?topic=3738.msg29472#msg29472

Kip, like I said, I can't reproduce this problem. And everything I say about it, is what I hear from other people in this forum. If someone comes and says he upgraded libcairo and the problem is gone, I can only suggest a libcairo update to other people.
Repeat: I can't reproduce this, at all.

kip · « **Reply #6 on:** August 28, 2006, 02:18:18 am »

Fair enough.

Are there any other additional debugging details I can give you? I rarely run gdb directly from command line, but I am sure I can work something out.

Kip

mandrav · « **Reply #7 on:** August 28, 2006, 08:34:02 am »

Quote from: kip on August 28, 2006, 02:18:18 am

Fair enough.

Are there any other additional debugging details I can give you? I rarely run gdb directly from command line, but I am sure I can work something out.

Kip

Is that the full backtrace up there?
Also, what graphics driver are you using? An ATI maybe? Can you start X using the framebuffer driver and see if this persists?

kip · « **Reply #8 on:** August 30, 2006, 01:02:25 am »

I just entered "bt" in GDB and that is the backtrace it spat out after C::B terminated. Is there a better way to get more detail?

I am using the fglrx ATI graphics driver in Ubuntu's package repository. How can I start X with the frame buffer device?

Kip

mandrav · « **Reply #9 on:** August 30, 2006, 05:22:44 pm »

Quote from: kip on August 30, 2006, 01:02:25 am

I just entered "bt" in GDB and that is the backtrace it spat out after C::B terminated. Is there a better way to get more detail?

No, "bt" alone displays the full backtrace. Let me look into this, although it's hard because I can't make it happen...

kip · « **Reply #10 on:** August 30, 2006, 09:01:29 pm »

Sounds good.

Kip

kip · « **Reply #11 on:** September 03, 2006, 07:59:27 pm »

Hey Mandrav,

I've done a lot of additional debugging and I have been working with the libcairo people. It is reproduceable and it has not been fixed in the latest version (1.2.4 at time of writing). I've narrowed it down to the line where the assert fails, the routine that failed previously, and the font that is probably causing the problem. More details here:

https://bugs.freedesktop.org/show_bug.cgi?id=8104

Until we find a work around or a fix, Code::Blocks will remain unusable.

--
Kip

mandrav · « **Reply #12 on:** September 03, 2006, 08:19:00 pm »

Interesting, thanks for the help.

kip · « **Reply #13 on:** September 03, 2006, 08:30:07 pm »

My pleasure, my friend. Is there any other info you need?

Kip

kai · « **Reply #14 on:** September 05, 2006, 02:19:41 pm »

i don't have any problems on one machine running dapper and constant crashing on my new laptop. the most obvious difference is that the laptop is a dual core machine. what about the others here who have problems or don't have problems?

kip · « **Reply #15 on:** September 05, 2006, 06:20:25 pm »

That is a very good point indeed. I have the problem on my dual core laptop as well.

Kip

Encryptor · « **Reply #16 on:** September 05, 2006, 07:46:11 pm »

I have the same problem on my dual-core CPU.

kip · « **Reply #17 on:** September 06, 2006, 04:16:20 am »

I think we have found a pattern.

Kip

mandrav · « **Reply #18 on:** September 06, 2006, 08:39:25 am »

Quote from: kip on September 06, 2006, 04:16:20 am

I think we have found a pattern.

Kip

Good thing that you reported it to the cairo people, Kip. Let's hope now that they can fix this bug (although something tells me none of them owns a dual-core cpu...).

kip · « **Reply #19 on:** September 06, 2006, 09:06:59 am »

You're probably right. None of them seem to be able to reproduce it. I've compiled latest from source and still the problem continues. I have a feeling that nobody is going to take this bug seriously though until it starts annoying one of the primary developers. I've done so much of the work already for them:

https://bugs.freedesktop.org/show_bug.cgi?id=8104

Kip

mandrav · « **Reply #20 on:** September 06, 2006, 10:03:06 am »

Few more questions:

Does this happen only with C::B?
Do you have any other wx-based apps?
Did you try to change the system font?

kip · « **Reply #21 on:** September 07, 2006, 06:43:03 am »

I'd try it with other apps, but I think just about everything on this system uses GTK. So I can't try it with other apps. But I have heard of the same problem having on the Win32 build as well. If you look at the bug report, I think I've narrowed it down to a specific font - but I am not sure. I really don't know much about libcairo or even what it's for.

Kip

Encryptor · « **Reply #22 on:** September 07, 2006, 07:14:09 pm »

Just a note:
I am using Sans Serif 9 for General Font and Monospace 9 for Fixed Width.
I changed General Font to Arial 9 and Fixed Width font to Courier new 9, and C::B still crashed when trying to save main.cpp. It gave the same libcairo error.

kip · « **Reply #23 on:** September 07, 2006, 08:40:10 pm »

Encryptor, are you on Win32?

I have changed my fonts around in Code::Blocks and to no avail.

This bug is a real challenge and it will feel great when it is squashed.

Kip

Encryptor · « **Reply #24 on:** September 08, 2006, 01:46:16 am »

No, I am using Ubuntu Linux 6.06.1

crzysdrs · « **Reply #25 on:** September 08, 2006, 10:08:09 pm »

I am also seeing this issue, Gentoo Linux. I coincidentally also have a dual core system. This cairo bug makes code blocks completely unusable due to the consistency of crashes.

mandrav · « **Reply #26 on:** September 08, 2006, 10:39:44 pm »

I think we can now safely attribute this bug to libcairo on dual core CPUs...
I know this doesn't make you feel any better, but at least it will be a starting point when the libcairo devs decide to look into it. I will try to nag them a bit...

(I haven't taken out the wx factor though)

kip · « **Reply #27 on:** September 12, 2006, 05:16:15 am »

I'm glad everyone's acknowledged the bug now. I've been in #cairo on freenode a few times. They are aware of it, but no one seems to care to fix it yet. If everyone who has noted the bug can confirm it with a note here:

https://bugs.freedesktop.org/show_bug.cgi?id=8104

...it may be enough to get the process in motion.

Kip

DrLock · « **Reply #28 on:** September 12, 2006, 11:13:07 pm »

I have posted a few more details to the cairo bug report, this may even be a FreeType problem (It is a FT function that is returning the errors).

In the meantime here is a .deb for AMD64 machines that has the assert() commented out (and debugging printf added). There is another assert at line 563 that fails once in a while, but I haven't taken it out.

http://www.drlock.com/projects/libcairo2_1.0.4-0ubuntu1_amd64.deb

kip · « **Reply #29 on:** September 13, 2006, 05:21:03 am »

Thanks DrLock. I've already tried rebuilding with the assert removed. Checkout the bug report and follow the comments. I did some debugging and I think I've narrowed it down to a possible culprit font.

Kip

Encryptor · « **Reply #30 on:** September 16, 2006, 04:21:40 am »

It doesn't crash so often now

Thanks!

jamesh · « **Reply #31 on:** September 16, 2006, 09:38:01 am »

Hi guys. I've been experiencing the same problem, on Ubuntu 6.06.1 with a P4 3Ghz with Hyperthreading enabled. The crash was extermely easy to reproduce - simply create a new Project -> new wxSmith project (didn't try other combination). Crashed every time.

However, I've just switched off HyperThreading in my BIOS and no longer have an issue ( http://en.wikipedia.org/wiki/Hyperthreading ). A quick and easy fix for P4 owners. Hope that's useful to someone - and that this bug gets squashed quickly. Thanks to all those helping to narrow the bug down.

Encryptor · « **Reply #32 on:** September 16, 2006, 11:36:35 pm »

Between "switching off Hyperthreading" and "commenting one line in libcairo", I choose the latter

Encryptor · « **Reply #33 on:** September 23, 2006, 01:13:57 am »

Ok, here's an interesting fact.
I disabled the Code completion plugin, and I did not have any crashes.

netzmeister · « **Reply #34 on:** October 07, 2006, 09:11:12 pm »

Quote from: Encryptor on September 23, 2006, 01:13:57 am

Ok, here's an interesting fact.
I disabled the Code completion plugin, and I did not have any crashes.

No, it still crashes..

bjm · « **Reply #35 on:** October 08, 2006, 09:20:15 am »

Last week I posted a followup comment to Bug #8579 in the C::B Berlios database.

There does appear to be a thread safety bug in the code completion plug-in. The
test patch I added seems to be working in that I haven't seen a crash since.

Currently I am only using a small subset of C::B features, so it's possible similar crashes
occur elsewhere in the code. The basic problem seems to be that the wxWidgets library
is not thread safe, and the code completion plug-in was not locking the required mutex
before updating the display. The abort in the cairo code is just a symptom of this.

I am also running a dual cpu box, so the crashes were very frequent.

The problem was tracked down by running C:B under gdb, and doing a backtrace of
all active threads after the crash (more details in the bug comment). You guys could try
a similar technique if you are seeing other cairo/GUI aborts.

I suggested the C::B developers review the patch in case it causes any nasty side effects
with features I am not using yet.

Hope this helps.

Cheers,
Barry.

killerbot · « **Reply #36 on:** October 08, 2006, 09:44:34 am »

can a few more "linux" dual core/cpu crash victims try the code changes mentioned at "http://developer.berlios.de/bugs/?func=detailbug&bug_id=8579&group_id=5358" out and test it. Just to see if there are other side effects ?
You can put your feedback over here.

Ceniza · « **Reply #37 on:** October 08, 2006, 10:59:48 pm »

I just did a clean compilation of Code::Blocks in Gentoo and it crashed in no time with that cairo problem. Applied those code changes and it seems to be working fine now.

P4 3.0 HT, just in case.

Game_Ender · « **Reply #38 on:** October 09, 2006, 03:05:35 am »

Very nice analysis by bjm there, I was very suspicious of this being a cairo problem, but of course I didn't look into the problem and have given up on CC for linux right now.

jheusala · « **Reply #39 on:** October 21, 2006, 12:15:17 pm »

Is there ways to run Code::Blocks only on one core or build it without thread support? It could be better short-term solution...

Der Meister · « **Reply #40 on:** October 21, 2006, 12:33:51 pm »

I don't think this would be possible. Code::Blocks uses multiple threads for good reasons.

Scheduling all of them on only one core would be possible - but this decision is up to your system, Code::Blocks does not have any influence on that.

jheusala · « **Reply #41 on:** October 21, 2006, 01:00:58 pm »

Quote from: Der Meister on October 21, 2006, 12:33:51 pm

Scheduling all of them on only one core would be possible - but this decision is up to your system, Code::Blocks does not have any influence on that.

That's right. I'm using Kubuntu Dapper. This helped for me:

Code

taskset 2 /usr/bin/codeblocks

PS: taskset is provided in the package schedutils.

News:

Author Topic: Constant Random Crashing (Read 28756 times)

kip

kip

kip

kip

kip

kip

kip

kip

kip

Encryptor

kip

kip

kip

Encryptor

kip

Encryptor

kip

DrLock

kip

Encryptor

jamesh

Encryptor

Encryptor

netzmeister

bjm

jheusala

jheusala