User forums > Using Code::Blocks

Code::Blocks unusable on Mac OS X 10.4

<< < (5/6) > >>

afb:

--- Quote from: thomas on March 12, 2008, 01:05:43 pm ---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.

--- End quote ---

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

--- End code ---

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:

--- Quote from: afb on March 13, 2008, 01:58:38 pm ---Another typical crash is:
--- End quote ---
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page