Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: erwincoumans on December 13, 2012, 11:19:29 pm

Title: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 13, 2012, 11:19:29 pm
My Code::Blocks install crashes, whenever I open a project, on Mac OSX, Mountain Lion 10.8.2 Macbook Pro 15" retina display.

It happens every time, so it is trivial to reproduce: create a C++ project, save it, exit CB, start CB, open that C++ project -> crash

Is this a known issue, do others have the same issue?

Thanks!
Erwin
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: polarbeardav on December 14, 2012, 01:25:38 am
This happens to me as well. I just upgraded to 12.11 and it is impossible to get any work done after the initial creation of a project in code::blocks. Same hardware as you.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: shaneknysh on December 14, 2012, 06:36:24 am
I am seeing the same issue.

There is a very old (2009) post that indicates the wxSmith plug-ins caused an error like this in the past. If I disable ALL the plug-ins the error is no longer reproducible but it makes the tool a bit less than useful.

I am slowly adding one plug-in at a time to see if I can find the one(s) triggering this problem.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: shaneknysh on December 14, 2012, 06:45:17 am
Code Completion is the culprit. Disable it in the manage plug-ins menu and loading a project no longer triggers a crash.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: Calexus on December 14, 2012, 04:50:14 pm
Not that it will help any of you but I don't have this problem running 12.11 on 10.7.5 imac. Maybe this is a 10.8 problem only?
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 14, 2012, 06:15:58 pm
Quote from: shaneknysh on December 14, 2012, 06:45:17 am
Code Completion is the culprit. Disable it in the manage plug-ins menu and loading a project no longer triggers a crash.

Yes, I can confirm that disabling the Code Completion plugin fixes the crash.

Code Completion seems to be a major new feature in this release so I hope it gets fixed soon.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: oBFusCATed on December 14, 2012, 09:24:22 pm
Quote from: erwincoumans on December 14, 2012, 06:15:58 pm
Code Completion seems to be a major new feature in this release so I hope it gets fixed soon.
Can you provide backtraces?
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 22, 2012, 04:14:14 am
Quote from: oBFusCATed on December 14, 2012, 09:24:22 pm
Quote from: erwincoumans on December 14, 2012, 06:15:58 pm
Code Completion seems to be a major new feature in this release so I hope it gets fixed soon.
Can you provide backtraces?
Sure, if you tell me how.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: oBFusCATed on December 22, 2012, 08:56:22 am
Quote from: erwincoumans on December 22, 2012, 04:14:14 am
Sure, if you tell me how.
I'm not a OSX user, so I'm not sure how. Probably you can attach to C::B with a debugger -> xcode, command line gdb/lldb
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 23, 2012, 06:23:33 pm
Who is creating the binary CodeBlocks release builds? Is someone maintaining CodeBlocks on Mac OSX?

I just ran COdeBlocks inside gdb and printed a backtrace, it seems extreme long (endless recursion?):
The message exceeds the maximum allowed length (20000 characters), so I cut some repeating parts:

Code
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb0104ffc
[Switching to process 3280 thread 0x7e0b]
0x0090e213 in wxEventHashTable::HandleEvent ()
(gdb) bt
#0  0x0090e213 in wxEventHashTable::HandleEvent ()
#1  0x0090e98f in wxEvtHandler::ProcessEvent ()
#2  0x00a55902 in wxWindowBase::TryParent ()
#3  0x0090e93c in wxEvtHandler::ProcessEvent ()
#4  0x00a55902 in wxWindowBase::TryParent ()
#5  0x0090e93c in wxEvtHandler::ProcessEvent ()
#6  0x00a55902 in wxWindowBase::TryParent ()
#7  0x0090e93c in wxEvtHandler::ProcessEvent ()
#8  0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#9  0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#10 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#11 0x0c53d953 in ClassBrowser::OnTreeItemCollapsing ()
#12 0x0090e0c3 in wxEvtHandler::ProcessEventIfMatches ()
#13 0x0090e23f in wxEventHashTable::HandleEvent ()
#14 0x0090e98f in wxEvtHandler::ProcessEvent ()
#15 0x00a55902 in wxWindowBase::TryParent ()
#16 0x0090e93c in wxEvtHandler::ProcessEvent ()
#17 0x00a55902 in wxWindowBase::TryParent ()
#18 0x0090e93c in wxEvtHandler::ProcessEvent ()
#19 0x00a55902 in wxWindowBase::TryParent ()
#20 0x0090e93c in wxEvtHandler::ProcessEvent ()
#21 0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#22 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#23 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#24 0x0c53d953 in ClassBrowser::OnTreeItemCollapsing ()
#25 0x0090e0c3 in wxEvtHandler::ProcessEventIfMatches ()
#26 0x0090e23f in wxEventHashTable::HandleEvent ()
#27 0x0090e98f in wxEvtHandler::ProcessEvent ()
#28 0x00a55902 in wxWindowBase::TryParent ()
#29 0x0090e93c in wxEvtHandler::ProcessEvent ()
#30 0x00a55902 in wxWindowBase::TryParent ()
#31 0x0090e93c in wxEvtHandler::ProcessEvent ()
#32 0x00a55902 in wxWindowBase::TryParent ()
#33 0x0090e93c in wxEvtHandler::ProcessEvent ()
#34 0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#35 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#36 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#37 0x0c53d953 in ClassBrowser::OnTreeItemCollapsing ()
#38 0x0090e0c3 in wxEvtHandler::ProcessEventIfMatches ()
#39 0x0090e23f in wxEventHashTable::HandleEvent ()
#40 0x0090e98f in wxEvtHandler::ProcessEvent ()
#41 0x00a55902 in wxWindowBase::TryParent ()
#42 0x0090e93c in wxEvtHandler::ProcessEvent ()
#43 0x00a55902 in wxWindowBase::TryParent ()
#44 0x0090e93c in wxEvtHandler::ProcessEvent ()
#45 0x00a55902 in wxWindowBase::TryParent ()
#46 0x0090e93c in wxEvtHandler::ProcessEvent ()
#47 0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#48 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()


...


#9226 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#9227 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#9228 0x0c53d953 in ClassBrowser::OnTreeItemCollapsing ()
#9229 0x0090e0c3 in wxEvtHandler::ProcessEventIfMatches ()
#9230 0x0090e23f in wxEventHashTable::HandleEvent ()
#9231 0x0090e98f in wxEvtHandler::ProcessEvent ()
#9232 0x00a55902 in wxWindowBase::TryParent ()
#9233 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9234 0x00a55902 in wxWindowBase::TryParent ()
#9235 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9236 0x00a55902 in wxWindowBase::TryParent ()
#9237 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9238 0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#9239 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#9240 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#9241 0x0c53d953 in ClassBrowser::OnTreeItemCollapsing ()
#9242 0x0090e0c3 in wxEvtHandler::ProcessEventIfMatches ()
#9243 0x0090e23f in wxEventHashTable::HandleEvent ()
#9244 0x0090e98f in wxEvtHandler::ProcessEvent ()
#9245 0x00a55902 in wxWindowBase::TryParent ()
#9246 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9247 0x00a55902 in wxWindowBase::TryParent ()
#9248 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9249 0x00a55902 in wxWindowBase::TryParent ()
#9250 0x0090e93c in wxEvtHandler::ProcessEvent ()
#9251 0x00a91be0 in wxGenericTreeCtrl::Collapse ()
#9252 0x00a88411 in wxGenericTreeCtrl::CollapseAndReset ()
#9253 0x0c5423df in ClassBrowserBuilderThread::CollapseItem ()
#9254 0x0c5454d7 in ClassBrowserBuilderThread::BuildTree ()
#9255 0x0c545795 in ClassBrowserBuilderThread::Entry ()
#9256 0x0090614d in wxThreadInternal::MacThreadStart ()
#9257 0x9201ba7b in PrivateMPEntryPoint ()
#9258 0x9849b557 in _pthread_start ()
#9259 0x98485cee in thread_start ()

Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: MortenMacFly on December 23, 2012, 09:56:00 pm
Quote from: erwincoumans on December 23, 2012, 06:23:33 pm
Who is creating the binary CodeBlocks release builds? Is someone maintaining CodeBlocks on Mac OSX?
Can you try to compile CC for C::B with the additional #define CC_NO_COLLAPSE_ITEM ?
Make sure you re-build at least this plugin. Then I guess it might work for you. Please report back, if that's the case.

Alternatively (if you want to play more), search for this snippet in classbrowserbuilderthread.cpp:
Code
#ifndef __WXGTK__
    m_CCTreeCtrlTop->CollapseAndReset(item); // this freezes gtk
#else
    m_CCTreeCtrlTop->DeleteChildren(item);
#endif
...and replace it with:
Code
#if !defined(__WXGTK__) && !defined(__WXMAC__)
    m_CCTreeCtrlTop->CollapseAndReset(item); // this freezes gtk
#else
    m_CCTreeCtrlTop->DeleteChildren(item);
#endif
Report back again...
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 23, 2012, 10:11:04 pm
I just tried to compiled CodeBlocks and its CodeCompletion plugin, but both failed either using autotools or CodeBlocks.cbp.

I rather not install wxWidgets system-wide, and it seems that is required to compile CodeBlocks. It would be nice if there is a source distribution that simply embeds all external dependencies using the right version (such as wxWidgets).
Code
./configure
configure: error: 
                wxWidgets must be installed on your system.

Trying to compile CodeBlocks using the src/CodeBlocks.cbp project gives another error:
Code
-------------- Build: Code-completion in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

g++ -Wall (invalid) -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN    -iquote.objs/include -I.objs/include -I. -I"(invalid)/include" -I"(invalid)/contrib/include" -I"(invalid)/lib/gcc_dll/mswu" -Isdk/wxscintilla/include -Isdk/wxpropgrid/include -Iinclude/tinyxml -Iinclude -Iinclude/mozilla_chardet  -c /Users/erwincoumans/Downloads/codeblocks-12.11release8629/src/plugins/codecompletion/ccoptionsdlg.cpp -o .objs/plugins/codecompletion/ccoptionsdlg.o
/bin/sh: -c: line 0: syntax error near unexpected token `('
Even if I manage to compile CodeBlocks (which I cannot, because I don't want to install wxWidgets system-wide),
I will not know where to define CC_NO_COLLAPSE_ITEM.

My previous questions it not answered: who created the binary Mac OSX build for the CodeBlocks release?
It seems the Mac OSX release with CodeCompletion is entirely untested, which I find surprising with such nice IDE.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: oBFusCATed on December 28, 2012, 06:47:48 pm
Quote from: erwincoumans on December 23, 2012, 10:11:04 pm
I rather not install wxWidgets system-wide, and it seems that is required to compile CodeBlocks.
You can install it locally and the you can pass the location to configure. Run ./configure --help for details.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 28, 2012, 10:55:24 pm
I just tried to compile wxWidgets and it fails, using the most up-to-date OS and Xcode version:

Code
Erwins-MacBook-Pro:wxWidgets-2.8.12 erwincoumans$ make
/Users/erwincoumans/Downloads/wxWidgets-2.8.12/bk-deps g++ -c -o basedll_dynlib.o -I./.pch/wxprec_basedll -D__WXMAC__     -DWXBUILDING -I./src/tiff -I./src/jpeg -I./src/png     -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/Users/erwincoumans/Downloads/wxWidgets-2.8.12/lib/wx/include/mac-ansi-release-2.8 -I./include -fpascal-strings -I./src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -DWX_PRECOMP -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -fno-common ./src/common/dynlib.cpp
In file included from ./include/wx/mac/private.h:4,
                 from ./src/common/dynlib.cpp:48:
./include/wx/mac/carbon/private.h:1459: error: ‘Cursor’ does not name a type
./include/wx/mac/carbon/private.h:1488: error: ‘ClassicCursor’ does not name a type
make: *** [basedll_dynlib.o] Error 1

According to this thread (https://github.com/mxcl/homebrew/issues/6672) there are issues with wxWidgets 2.8.x and wxWidgets 2.9.x should be used.

To encourage contributors to help fixing CodeBlocks, please provide a self-contained source tarball that simply builds out-of-the-box.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: oBFusCATed on December 28, 2012, 11:02:53 pm
Quote from: erwincoumans on December 28, 2012, 10:55:24 pm
According to this thread (https://github.com/mxcl/homebrew/issues/6672) there are issues with wxWidgets 2.8.x and wxWidgets 2.9.x should be used.
Have you tried this: https://github.com/mxcl/homebrew/issues/6672#issuecomment-1821305 ?

Unfortunately cb is not very usable when built with wx2.9 even on linux/windows...
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: erwincoumans on December 28, 2012, 11:09:37 pm
MacOSX10.6.sdk is not installed with the most up-to-date Xcode, only MacOSX10.7 and MacOSX10.8.

I'll wait until CodeBlocks supports wxWidgets 2.9 and learn how to use Xcode in the meanwhile.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: oBFusCATed on December 28, 2012, 11:46:17 pm
But you can install older xcodes, I suppose.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: MortenMacFly on December 29, 2012, 06:48:37 am
Quote from: erwincoumans on December 28, 2012, 10:55:24 pm
To encourage contributors to help fixing CodeBlocks, please provide a self-contained source tarball that simply builds out-of-the-box.
Well we do that using autotools, or C::B itself.
The problem is that we have dependencies on third party libs that maybe not easily to be resolved by everybody:
- boost
- hunspell
- fam
If you know how to get these for the Mac - do this in advance, the dependency on wxWidgets is clear, I think.
But if you disable the plugins that make use of it (for me it was NassiShneidermann, SpellChecker, FileManageer) the build should just succeed. Then you have to build a package for which there was a script just posted recently which I am trying to understand (I am not an Mac user and never will be, so and this "App package foo" is new to me). But once ready, this script should just work.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: Calexus on January 18, 2013, 10:29:42 am
About that, last time I tried to build codeblocks using the provided workspaces it would not work without quiet a bit of changes. From compiling to linking, missing headers and undefined defines, .dylib fils instead of .so files und so weiter. I don't know it has been updated since then, with the new release and all, but at least then building codeblocks was not that easy. And on top of that we have appels crappy version of wx, and probably some other stuff I have forgot about.
Title: Re: Crashes with Code::Blocks 12.11 rev 8629 on Mac OSX
Post by: MortenMacFly on January 18, 2013, 10:48:44 am
Quote from: Calexus on January 18, 2013, 10:29:42 am
About that, last time I tried to build codeblocks using the provided workspaces it would not work without quiet a bit of changes.
It should work now just fine when building C::B using C::B and running the update and mac_pack script afterwards. Of course you need a wxWidgets compiled before. And yes, there have been changes recently to the build system and C::B itself to make it work.

Quote from: Calexus on January 18, 2013, 10:29:42 am
instead of .so files und so weiter
LOL.