Code::Blocks unusable on Mac OS X 10.4

[atari_eric]

Mind you, I have used both the Linux and Windows versions of this program for a few months, and I otherwise think it's a great program, but:

The Mac OS X build of Code::Blocks is completely unusable.

It takes a good few minutes to even load up - even XCode boots up faster (I'm trying to find a lighter weight IDE, not more bloatware), and this is after I delete the truckful of unnecessary plugins you have deemed to have pre-installed.  It takes *5 seconds* just for the setup page to come up - and the "OK" butons are off the bottom of the screen!  It doesn't help that the completely unnecessary menu graphics take up a quarter of the screen...

It is a real shame to see a program with such potential become riddled with such quality-critical bugs.  I am a professional programmer myself, and I if a project I was working on put out a "big" release such as this with bugs as bad as these, my team would not only be fired on the spot, but blacklisted from the industry to make sure they either learned their lesson, or starved on the street regretting their incompetence.

I am assuming the reason the Mac build is how it is is because there are few (if any) Mac programmers contributing to the project.  I wish I was more skilled at Mac programming (and had more free time) as I'd rather fix a problem, rather than just complain about it.  I only hope that this post calls attention to the state of the Mac build so that other Mac programmers can make this program the work of art it should be.

Good Luck,
Eric.

[afb]

I am assuming the reason the Mac build is how it is is because there are few (if any) Mac programmers contributing to the project.  I wish I was more skilled at Mac programming (and had more free time) as I'd rather fix a problem, rather than just complain about it.  I only hope that this post calls attention to the state of the Mac build so that other Mac programmers can make this program the work of art it should be.

You are right about the number of Mac users and developers...

But your quality-critical bug list seems to be something like:

• It is too slow to use, especially when initially starting up
• It has too many plugins (currently everything is included)
• It runs poorly on a smaller screen (was only tested on 17")

Doesn't really give too much to go on for development, does it ?
Beyond "make it faster", and "test the UI with more screen sizes"

[_Andrey_]

The Mac OS X build of Code::Blocks is completely unusable.

You right, Code::Blocks for Mack OS X not usable at this moment. Previously i use XCode, then try to switch to Code::Blocks. But i think that i should switch back to XCode.

Code::Blocks works fine on Windows and Linux only

[Auria]

Yeah the mac version will need more work. I considered contributing some time ago, but then wxScintilla (and wxAUI in general) is so awful slow on my computer (on mac mostly, on linux it's a bit better, though still not as fast as XCode), I finally gave up on it since I knew I wouldn't use it. Not sure what makes wxScintilla so slow on mac, it would need profiling - also not sure what makes it so slow to open

I personnaly didn't really have any problems with size, yet I have a small screen with low resolution... anyway that's not really a C::B problem, all programs will look like that if your screen is not as big as needed for your work (even though, I agree many dialogs would need improved layout and do not currently fit)

I am a professional programmer myself, and I if a project I was working on put out a "big" release such as this with bugs as bad as these, my team would not only be fired on the spot, but blacklisted from the industry to make sure they either learned their lesson, or starved on the street regretting their incompetence.

Come on, that's close to trolling. Your project is obviously not developed by volunteers in their free time - no comparison is possible.

[Seronis]

I have a friend who teaches various computer courses at my old highschool that is always looking for new stuff.  I've suggested C::B in the past but it was rejected as there was no official release to base classwork from.  With this past months release I was thinking if bringing it up again as I've noticed quite consistant improvements non stop since I've been using C::B.  Problem is i use linux and windows and the school is almost entirely OS X (only the finance classes use windows, and no linux at all).

I literally havent used a mac in nearly 15 years so have no clue what kind of issues they would have.  The setup instructions seem straight forward enough, but is C::Bs performance really so bad on the new apples?  Could any additional Mac users please put in some comments on your good and bad experiences when using C::B?  Id love to be able to link to the list of responses so that my friend would be able to make an informed decision rather than myself just saying "it works great on XP and Ubuntu".

[afb]

Also; if you are having major problems with the "wxMac" (Aqua) version of Code::Blocks, it is possible to build a "wxGTK" (X11) of Code::Blocks that runs on Mac OS X (with the bundled X11.app from Apple installed)...

The easiest way to do this is to install MacPorts and run this installation command:

Code

sudo port install codeblocks +x11

It will build GTK+ and wxWidgets as needed, then you can start it with: codeblocks

[Seronis]

Is that a more stable way?  If so, is there any way a build of 8.02 could be released built in that manner?

[afb]

Is that a more stable way?

The wxGTK port seems somewhat more stable, but I guess we'll see how it works for the people that are having problems with the wxMac version first - and whether X11 is acceptable or not...

If so, is there any way a build of 8.02 could be released built in that manner?

Sure, if there is enough demand there could be a version built that bundles GTK+ and wxGTK and doesn't require MacPorts installed. It will require Xcode Tools* and X11.app installed though.

* don't really need the whole Xcode.app, but do need the GCC (compilers) and SDK (headers/libraries)

[matjam]

I am not a seasoned Mac programmer but I am using Code::Blocks and unfortunately CB for Mac is quite unstable. While it may load slower than on other platforms that is not the main issue.

One of the main issues that I have experienced is debugging. I am using the latest Apple version dbg with gdc frontend for D language and whenever I attempt to debug an application if I have not set more than two breakpoints the program does not break and when I attempt to stop the debugger from CB the application bombs out and take any other running programs with it.

A second major problem is that on random occasions trying to open a source file from the project panel will exit the program. This is random and I haven't found a repeatable way to cause this crash.

Currently I am having to evaulate if XCode might be the way to go though I'd love to use CB as this is the IDE we are using on Windows and Linux.

[pphoss23]

I installed version 8.02 on Mac OS X 10.4.11 yesterday.
I have been using codeblocks on Windows and Linux for the past year or so. It's a useful tool. Thanks to the developers.
On my mac ( G5 Desktop, Dual 2.5 Ghz, 1.5 GB Mem ), Codeblocks is very unstable. It crashes right after I load a project or workspace 8 out of 10 times.
The crash report is this: (It's long, sorry!)



[attachment deleted by admin]

[afb]

The crash report is this: (It's long, sorry!)

OK, at least that gives the point when the thread crashed...

Code

Thread 1 Crashed:
0   libwx_macu-2.8.0.dylib         	0x01586c1c wxMBConv::cWC2MB(wchar_t const*) const + 188
1   libwx_macu-2.8.0.dylib         	0x01553354 wxAccess(wchar_t const*, int) + 52
2   libwx_macu-2.8.0.dylib         	0x015487a4 wxFile::Access(wchar_t const*, wxFile::OpenMode) + 52
3   libcodeblocks.0.dylib          	0x010b3184 FileLoader::operator()() + 36
4   libcodeblocks.0.dylib          	0x012bbb08 BackgroundThread::Entry() + 152

[MortenMacFly]

OK, at least that gives the point when the thread crashed...

Code

Thread 1 Crashed:
0   libwx_macu-2.8.0.dylib         	0x01586c1c wxMBConv::cWC2MB(wchar_t const*) const + 188
1   libwx_macu-2.8.0.dylib         	0x01553354 wxAccess(wchar_t const*, int) + 52
2   libwx_macu-2.8.0.dylib         	0x015487a4 wxFile::Access(wchar_t const*, wxFile::OpenMode) + 52
3   libcodeblocks.0.dylib          	0x010b3184 FileLoader::operator()() + 36
4   libcodeblocks.0.dylib          	0x012bbb08 BackgroundThread::Entry() + 152

This reminds me on a discussion where Thomas insisted that this code cannot fail... Now Thomas: See?! ;-)
I had the same issue on Windows rarely btw. I even know that I fixed it by doing something not really obvious... unfortunately I have forgotten what it was. :-(

[thomas]

This reminds me on a discussion where Thomas insisted that this code cannot fail... Now Thomas: See?! ;-)

All I do see is that the crash happens inside wxFile::Access(fileName, wxFile::read) on a (entirely unnecessary) character set conversion.
So? What are you trying to tell me?
fileName is a wxString member of the containing class. It is properly and provably initialised in LoaderBase (first, C++ doesn't allow any different, and second, the crash would otherwise happen on the assignment inside FileLoader's constructor already). There are no other modifications to that object during its lifetime.
wxFile::Access is a perfectly legal function to call, unless I am grossly mistaken? So really, from the application's point of view, I can't see how this could crash in a legal environment.

If it crashes on Mac, then I'm really sorry... complain to the wxMac guys, or buy a PC, is all I can say.

[Maciek]

I am a professional programmer myself, and I if a project I was working on put out a "big" release such as this with bugs as bad as these, my team would not only be fired on the spot, but blacklisted from the industry to make sure they either learned their lesson, or starved on the street regretting their incompetence.

Come on, that's close to trolling. Your project is obviously not developed by volunteers in their free time - no comparison is possible.

OP may be right. It's not that state of Mac version itself is something bad. As you said it's made entirely by volunteers and nobody should complain, and just be grateful to all the devs. The problem is it's listed as a stable build next to Windows and Linux versions. Take your time, smash the bugs whenever you want, just make it clear that Mac build is not ready for day-to-day use, and it's more of a preview.

That said, I've never used it myself, so disregard all this in case OP is exaggerating.

[Ceniza]

I think that's the same crash I saw when I tried CB on Mac. It looked like a perfectly valid call, but, somehow, it caused a very funny behavior. At some point a new wxString was created, but requesting a huge amount of memory space, which made malloc() fail and finally crash the application. I stopped working on that bug because I couldn't really find anything to blame, and debugging CB on Mac was slow as Hell (tm).

Good look trying to solve that nasty bug.

[Auria]

Is that a more stable way?

The wxGTK port seems somewhat more stable, but I guess we'll see how it works for the people that are having problems with the wxMac version first - and whether X11 is acceptable or not...

If so, is there any way a build of 8.02 could be released built in that manner?

Sure, if there is enough demand there could be a version built that bundles GTK+ and wxGTK and doesn't require MacPorts installed. It will require Xcode Tools* and X11.app installed though.

I'm somewhat involved in the mac port of GIMP, and all I can say is, stay as far from X11.app as you can... every week we get something in X11 broken, sometimes they arbitrarly change config files location, it was broken many times on leopard, it contains many broken libs on tiger, ilaunching method was chaned on leopard, it sometimes installs in /usr/X11, sometimes in /usr/X11R6, the updates you can download online install libraries versions older than the ones you previously had, it opens windows out of the screen, it causes memory corruption on many operations and causes crases... In sort, X11.app on mac is total hell  :lol: better fix the native version.

I sould really take a look at it and try to fix some bugs. Now if I could get a faster computer, so that speed is a bit less of an hell

i also agree there should be some mention that the mac version may not be as stable as others (somewat embarrassing snce i recently asked for the mac verson to be listed on the website, however i didn't think it would be marked as stable as others)

[afb]

I'm somewhat involved in the mac port of GIMP, and all I can say is, stay as far from X11.app as you can... every week we get something in X11 broken, sometimes they arbitrarly change config files location, it was broken many times on leopard, it contains many broken libs on tiger, ilaunching method was chaned on leopard, it sometimes installs in /usr/X11, sometimes in /usr/X11R6, the updates you can download online install libraries versions older than the ones you previously had, it opens windows out of the screen, it causes memory corruption on many operations and causes crases... In sort, X11.app on mac is total hell  :lol: better fix the native version.

As mentioned, both are available in MacPorts and wxGTK is slightly "better" (even if the wxgtk port is older than the other - uses 2.8.4 ANSI still). X11.app was rather broken, but is better now with 10.5.2 and the included updates from the Xquartz project. As for the install locations it was /usr/X11R6 on Tiger (XFree86-based), but is /usr/X11 on Leopard (Xorg-based) though there is a compat symlink from the old location so it should still work.

But yes you are right, wxMac is still the primary platform - no question about that...

[afb]

BTW, I will probably continue with the "nightly builds" (usually more like monthly) so any bugfixes made should be available even before the next release is out (next up is 20080310_rev4943). So if you do have some Mac patches for Code::Blocks (or wxWidgets for that matter), do send them in...

http://developer.berlios.de/project/showfiles.php?group_id=5358

[Auria]

As for the install locations it was /usr/X11R6 on Tiger (XFree86-based), but is /usr/X11 on Leopard (Xorg-based) though there is a compat symlink from the old location so it should still work.

Well it should, but in practice we learned that in some cases the symlink is simply not there, no clue why

So if you do have some Mac patches for Code::Blocks (or wxWidgets for that matter), do send them in...
http://developer.berlios.de/project/showfiles.php?group_id=5358

Well I did send a very humble patch there, though it got no answer. (Maybe it's bad, please just tell me so if it's the case  )

[afb]

Well I did send a very humble patch there, though it got no answer. (Maybe it's bad, please just tell me so if it's the case  )

Applied now. (patch #2305, r4945)

[afb]

wxFile::Access is a perfectly legal function to call, unless I am grossly mistaken? So really, from the application's point of view, I can't see how this could crash in a legal environment.

If it crashes on Mac, then I'm really sorry... complain to the wxMac guys, or buy a PC, is all I can say.

Another typical crash is:

Code

Thread 5 Crashed:
0   libwx_macu-2.8.0.dylib         	0x08b649ae wxMBConv::cWC2MB(wchar_t const*) const + 104
1   libwx_macu-2.8.0.dylib         	0x08b393ed wxStat(wchar_t const*, stat*) + 43
2   libwx_macu-2.8.0.dylib         	0x08b39448 wxFileExists(wxString const&) + 26
3   libcodecompletion.so           	0x17a44e5c Parser::FindFileInIncludeDirs(wxString const&, bool) + 220 (parser.cpp:792)
4   libcodecompletion.so           	0x17a451a4 Parser::FindFirstFileInIncludeDirs(wxString const&) + 108 (parser.cpp:773)
5   libcodecompletion.so           	0x17a49be5 Parser::GetFullFileName(wxString const&, wxString const&, bool) + 119 (parser.cpp:821)
6   libcodecompletion.so           	0x17a4bda2 ParserThread::HandleIncludes() + 194 (parserthread.cpp:920)
7   libcodecompletion.so           	0x17a53b7f ParserThread::DoParse() + 8985 (parserthread.cpp:463)
8   libcodecompletion.so           	0x17a552cc ParserThread::Parse() + 76 (parserthread.cpp:333)
9   libcodecompletion.so           	0x17a6c861 ParserThread::Execute() + 17 (parserthread.h:75)
10  libcodeblocks.0.dylib          	0x01a34133 cbThreadPool::cbWorkerThread::Entry() + 183 (thread.h:176)
11  libwx_macu-2.8.0.dylib         	0x08b96678 wxThreadInternal::MacThreadStart(void*) + 142

[MortenMacFly]

...after a short chat with Yiannis I have updated the wxScintilla component in SVN. Mind updating / trying the MAC build again whether this probably increases speed (a lot/slightly/not at all)?! Thanks! :-)

[thomas]

Another typical crash is:

Different API function, same thing.

Conversion from wxString to wchar_t* to UTF-8 char*, and crash. Looking at the awful mess in strconv.[h|cpp], I'm not surprised either... function pointers to #ifdef sections typed through 3 layers of #defines and typedefs, and half a dozen special cases. You can't even figure out which function is actually called in under half an hour...

Either way, since the crash happens during the wx-internal string conversion to "system", there's nothing we can do about it,... except not calling any functions that might possibly open a file, read a directory, or otherwise involve a string which might possibly be passed to the operating system... which kind of makes an IDE absurd.

[afb]

Makes you wonder if it wouldn't be "easier" to use the ANSI version of wxWidgets instead...

[Auria]

Well wx 3 will be Unicode-only so maybe there will be less problems

What would need to be investigated, though, is why C::B is the only app (well that i know of but i know quite a few) that makes this feature crash - dozens of mac wxApps use these features without problems. I'll try looking at it if I have time.

Morten: am building now

[Auria]

...after a short chat with Yiannis I have updated the wxScintilla component in SVN. Mind updating / trying the MAC build again whether this probably increases speed (a lot/slightly/not at all)?! Thanks! :-)

I have built revision 4953. I did not do any benchmark, but unfortunately I did not notice much speed improvements during editing (though, was there something specific I should have checked? not knowing what change to expect it's a bit hard to tell)

I know the CodeLite author added caching code into his wxScintilla, making it significantly faster (on linux too), maybe that's a possible target?