wxMac threading crash issues

[afb]

"[ 1901956 ] wxMac: TECConvertText not thread safe"

It seems that the mac carbon function TECConvertText is not thread safe.
This causes problems in applications that use say wxFileExists() and
friends in separate threads. Applications that make calls to
TECConvertText in separate threads crash randomly sooner or later.

^ the above would be Code::Blocks

[afb]

I have applied the suggested patch to my wxWidgets (libwx_macu_gl-2.8.0.4.0.dylib), so it will go out with the next nightly. It seems to fix the threading issues / application crashes, at least I can't provoke it the same way now.

[thomas]

Ah darn, I had just written a Mac-stupefier for those functions in Code::Blocks... but well, it's probably nicer if you just use a patched wxMac and that crap that stays out of our sources.

[afb]

Ah darn, I had just written a Mac-stupefier for those functions in Code::Blocks... but well, it's probably nicer if you just use a patched wxMac and that crap that stays out of our sources.

Taking a wxMutex on all file access ? Or did you do something that the patch won't fix ?

[thomas]

Taking a wxMutex on all file access ? Or did you do something that the patch won't fix ?

No, just that... a self-locking wrapper for the two problematic functions.

But it's of course preferrable to have it patched into wxMac. Not only does it not pollute the Code::Blocks sources that way, but it also requires less changes and fixes yet unknown issues with future contrib plugins (whose authors might not know).

[tiger683]

Hi,
Due to lack of a current nightly for mac, i have (once again) tried to use c::b with my self-compiled
version of wxMac-2.8.7 after patching it with the suggested patch (i use c::b for development on all supported platforms and the most cmmon instability in my case seems to be due to exactly the very threading bug -> very often crashes).

As with all previous home-baked wxMac of mine, niether the official 8.02 nor a self-compiled svn have the compile-target wxChoice in the compiler toolbar.

afb: could you point out how differen is the wxMac build included in the code::blocks distributions from what one might get by hand-compiling a current wxMac release? (pathes/configue options/anything...).

Thanks in advance,
This way i might also be able to help in testing anything new meant for the mac releases

Rafael

[afb]

Due to lack of a current nightly for mac, i have (once again) tried to use c::b with my self-compiled
version of wxMac-2.8.7 after patching it with the suggested patch (i use c::b for development on all supported platforms and the most cmmon instability in my case seems to be due to exactly the very threading bug -> very often crashes).

As with all previous home-baked wxMac of mine, niether the official 8.02 nor a self-compiled svn have the compile-target wxChoice in the compiler toolbar.

afb: could you point out how differen is the wxMac build included in the code::blocks distributions from what one might get by hand-compiling a current wxMac release? (pathes/configue options/anything...).

There are two patches applied, one for making the default selection the same in configure as it is in Xcode:

Code

--- include/wx/mac/carbon/chkconf.h	2007-05-14 11:09:36.000000000 +0200
+++ include/wx/mac/carbon/chkconf.h	2007-05-21 10:59:19.000000000 +0200
@@ -55,7 +55,7 @@
  */
 
 #ifndef wxMAC_USE_NATIVE_TOOLBAR
-    #define wxMAC_USE_NATIVE_TOOLBAR 1
+    #define wxMAC_USE_NATIVE_TOOLBAR 0
 #endif
 
 #endif

For comparison, the Xcode header (include/wx/mac/setup0.h) says:

Code

// native toolbar does not support embedding controls yet, please test by setting to 1
#define wxMAC_USE_NATIVE_TOOLBAR 0

The other was the recent patch to fix the threading issues with filenames and string conversions:

https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1901956&group_id=9863


And here is the configuration:

Code

./configure --enable-universal_binary --with-mac --with-opengl --enable-monolithic --enable-unicode --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin --with-expat=builtin

[tiger683]

Thanks

All works nicely now, and i can say this resolves most of the mac stability issues I've had so far.
The only one still remaining is C::B closing itself / crashing without a crashreport when i terminate a debug session of a running debuggee from within the debugger toolbar.

I might post a bugreport on this one if it wasn't already reported Will check.

Regards,

Rafael