Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: EKrunk on February 07, 2014, 08:46:08 pm

Title: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: EKrunk on February 07, 2014, 08:46:08 pm
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]
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: Jenna on February 07, 2014, 10:03:15 pm
Quote from: EKrunk on February 07, 2014, 08:46:08 pm
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 (http://www.codeblocks.org/downloads/26#mac)
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: EKrunk on February 07, 2014, 11:06:40 pm
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
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: EKrunk on February 07, 2014, 11:10:14 pm
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
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.

Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: caflor on February 21, 2014, 12:55:36 pm
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
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: BlueHazzard on February 21, 2014, 01:24:11 pm
simple and quick solution: don't use spaces/special character in your paths...
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: EKrunk on February 21, 2014, 08:33:24 pm
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.
Title: Re: Mac 10.8.5: Crash on opening project in CB 12.11
Post by: stahta01 on February 21, 2014, 08:44:33 pm
Quote from: EKrunk on February 21, 2014, 08:33:24 pm
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.
Title: Re:
Post by: MortenMacFly on February 21, 2014, 10:03:57 pm
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.