Bug #8579 2006-08-25 21:14

kiplingw

Crashes Randomly During Use

Code::Blocks crashes randomly during use. I am using the latest subversion source and the latest libcairo out of Ubuntu's edgy repository.

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

Aborted

Kip

Category
Application::Crash
Group
 
Status
Closed
Close date
2006-10-17 23:48
Assigned to
 
ID_32261 2006-10-03 11:27
Further information to assist developers for this and closed/duplicate Bug #7968.

Since downloading CodeBlocks a few days ago, I have the same problem with it crashing almost every time a file is saved.

The save can be either explicit, or a result of performing a build with a modified file open.

Platform: Linux Fedore Core 5 x86, updated to latest libraries (wxWidgets, pango, cairo etc.)

CodeBlocks version. Local build, SVN checkout from trunk on Sunday 1st October 2006. 
Was also crashing with rpm :- codeblocks-1.0-0.9.20060909svn2965.fc5

I am running CodeBlocks on an old dual CPU machine, usually good for highlighting thread safety/synchronization bugs.

Investigation steps and results:-

Ran CodeBlocks  under gdb (actually 'ddd' GUI), ie.
% ddd /usr/local/bin/codeblocks

Do stuff to cause failure.., in this case not identical to original report but similar enough.

codeblocks: cairo-ft-font.c:562: _cairo_ft_unscaled_font_unlock_face: Assertion 
`unscaled->lock > 0' failed.

gdb had caught the SIGABRT. The assertion failure had occurred in the main CodeBlocks GUI App thread.
Used gdb to list other active threads (about 7) and performed a backtrace for each. Found another thread appeared to be executing wx library code below method :- ClassBrowserBuilderThread::Entry().

Since wxWidgets is documented as NOT thread safe, tried adding a test patch as below (the ::wxMutexGuiEnter()/::wxMutexGuiLeave()).
This should prevent simultaneous access by the worker and main GUI threads.

<code>

FILE:- ..trunk/src/plugins/codecompletion/classbrowserbuilderthread.cpp

void* ClassBrowserBuilderThread::Entry()
{
    while (!TestDestroy())
    {
        // wait until the classbrowser signals
        m_Semaphore.Wait();
//        DBGLOG(_T(" - - - - - -"));

        if (TestDestroy())
            break;

	// BJM experimantal patch, ensure exclusive access to 
        // wx GUI library.
        if(!::wxIsMainThread())
	    ::wxMutexGuiEnter();

        BuildTree();

// BJM experimantal patch, ensure exclusive access to 
        // wx GUI library.
        if(!::wxIsMainThread())
	    ::wxMutexGuiLeave();
    }
...
</code>

Since the above change I have not (yet) had any further crashes. However, it would be unwise to accept this as the final 'fix'. I have only used CodeBlocks for a few days and don't know the code very well. There could be other unwanted side effects or potential mutex deadlocks I haven't spotted. This needs review by the developers, when they get time.

If anybody else sees similar/random crashes which may be related to GUI access, it may be
worth trying the same approach with gdb, ie. get a stack trace for each thread as evidence for the developers. Note: 'ddd' doesn't seem to have a working 'copy to clipboard' function in its backtrace display window (my excuse for not including any!). The SVN checked out sources currently build with debug symbols by default.

Hope this is helpful to somebody.

Many thanks to the developers for making CodeBlocks available to the world.
































































kiplingw 2006-10-18 04:17

It hasn't crashed on me yet. Well done. You've saved me a shit load of time.

Kip