Mac 10.8.5: Crash on opening project in CB 12.11

[EKrunk]

Hello all...

I just downloaded the latest CB (12.11) on Mac OS 10.8.5.  When it opens, and I try to open a new project, I consistently get a crash.  Plus, it takes a long time to open, and I have to click on the dock icon in order to bring the application to the front and make it active.

I have four crashstacks (attached).  Two are after creating a (console) project, and then clicking on "main" to edit main.c, when a crash occurs.  Others are from trying to open an existing project (which was left after the earlier crashes, so that might be part of the problem).

I'm guessing this works for some people on the Mac, so I was hoping to get some ideas of some configuration that CB is not happy with.

Thanks!


-Eric


[attachment deleted by admin]

[Jenna]

I just downloaded the latest CB (12.11) on Mac OS 10.8.5.

12.11 is not the latest revision, please try 13.12 and give feedback.
http://www.codeblocks.org/downloads/26#mac

[EKrunk]

Ah, much better!  Not sure how I got 12.11 instead of 13.12, but anyway I have it now, and it hasn't crashed so far.

Thanks!

-Eric

[EKrunk]

I should probably start another thread, but since I"m here...

It seems CB can't handle project names with embedded spaces (at least on the Mac).  When I try to run one I get:

Code Select Expand

Last login: Fri Feb  7 17:07:11 on ttys005
[1] ~% /bin/sh -c '/Applications/Utilities/CodeBlocks.app/Contents/MacOS/cb_console_runner DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:. /Volumes/Projects/CodeBlocks/Binary Search/bin/Debug/Binary Search '
sh: /Volumes/Projects/CodeBlocks/Binary: No such file or directory

The spaces inside the command string being sent to the shell need to be quoted or otherwise escaped.

[caflor]

Hi EKrunk,

I am having the same issue...no such file or directory.

I am copying printf code straight from the book (C Programming by Perry and Miller, 2014) and it builds with no bugs or errors but when the run function is executed, the terminal window labeled bash gives me the same response, ...no such file or directory.

caflor

[BlueHazzard]

simple and quick solution: don't use spaces/special character in your paths...

[EKrunk]

I wouldn't call that a solution, I'd call it a workaround.

I would call the current behavior a "bug".  In this day and age, spaces are common in file and directory names.  To have things fail (with no advanced warning) if you have file/directory names with spaces in them, feels all kinds of ancient (like the DOS days).

Just my opinion, YMMV.

[stahta01]

I wouldn't call that a solution, I'd call it a workaround.

I would call the current behavior a "bug".  In this day and age, spaces are common in file and directory names.  To have things fail (with no advanced warning) if you have file/directory names with spaces in them, feels all kinds of ancient (like the DOS days).

Just my opinion, YMMV.

Feel free to submit a patch that fixes the issue.

Tim S.

[MortenMacFly]

There is no need for a fix.You can enable to use 8.3 file names in the compiler options. Then the path to the object files in the executable will work with gdb as expected. Note that this use a gdb limitation, not a c::b one.