First of all, lionel, you are a better man than I. Second, here's a phrase for you to learn: "Fuck off, Kry".
Now, your narrowing down the interval will no doubt help in finding the long long bug. Unfortunately, I've been (lazily) living with that bug in my aMule for quite some time. For me, it's only cosmetic. aMule runs fine but displays certain values incorrectly. So, the crashes you're experiencing may be due to some other unknown bug.
...
OK, so this is the change that caused the problem:
Index: include/wx/wxchar.h
===================================================================
RCS file: /pack/cvsroots/wxwidgets/wxWidgets/include/wx/wxchar.h,v
retrieving revision 1.190
retrieving revision 1.191
diff -u -r1.190 -r1.191
--- include/wx/wxchar.h 2006/03/09 13:16:02 1.190
+++ include/wx/wxchar.h 2006/03/17 14:26:59 1.191
@@ -4,7 +4,7 @@
* Author: Joel Farley, Ove KÂven
* Modified by: Vadim Zeitlin, Robert Roebling, Ron Lee
* Created: 1998/06/12
- * RCS-ID: $Id: wxchar.h,v 1.190 2006/03/09 13:16:02 VZ Exp $
+ * RCS-ID: $Id: wxchar.h,v 1.191 2006/03/17 14:26:59 SC Exp $
* Copyright: (c) 1998-2002 Joel Farley, Ove KÂven, Robert Roebling, Ron Lee
* Licence: wxWindows licence
*/
@@ -880,7 +880,8 @@
#if defined(HAVE__VSNWPRINTF)
#define wxVsnprintf_ _vsnwprintf
/* MinGW?MSVCRT has the wrong vswprintf */
- #elif defined(HAVE_VSWPRINTF) && !defined(__MINGW32__)
+ /* Mac OS X has a somehow buggy vswprintf */
+ #elif defined(HAVE_VSWPRINTF) && !defined(__MINGW32__) && !defined(__DARWIN__)
#define wxVsnprintf_ vswprintf
#endif
#else /* ASCII */
Unfortunately, that only means that wx switched from using the built-in vswprintf to using wx's own implementation of that function. And it doesn't explain why, really ("somehow buggy").
The real problem is that wx's implementation is itself buggy, so they switched from one perhaps-buggy implementation to a definitely buggy one. And the change doesn't help us figure out why the wx implementation is buggy.