Constant Random Crashing

[Encryptor]

It doesn't crash so often now Thanks!

[jamesh]

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]

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

[Encryptor]

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

[netzmeister]

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

No, it still crashes..

[bjm]

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]

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]

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]

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]

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]

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]

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 Select Expand

taskset 2 /usr/bin/codeblocks

PS: taskset is provided in the package schedutils.