OK, we knew there was a crashing bug lurking in wxMac's unicode support and I hit it. Here's a partial backtrace (I've removed parts that are clearly unimportant):
Program received signal EXC_BAD_ACCESS, Could not access memory.
0xffff8cc0 in __memcpy ()
(gdb) bt
#0 0xffff8cc0 in __memcpy ()
#1 0x901952d0 in __CFStringCreateImmutableFunnel3 ()
#2 0x901adf48 in CFStringCreateWithCharacters ()
#3 0x002d13b8 in wxMacCFStringHolder::Assign(wxString const&, wxFontEncoding) (this=0xbfffe5b0, st=@0xbd45ab4, encoding=wxFONTENCODING_DEFAULT) at ../wxWidgets/src/mac/corefoundation/cfstring.cpp:645
#4 0x0062e018 in wxMacCFStringHolder::wxMacCFStringHolder(wxString const&, wxFontEncoding) (this=0xbfffe5b0, str=@0xbd45ab4, encoding=wxFONTENCODING_DEFAULT) at ../wxWidgets/include/wx/mac/corefoundation/cfstring.h:45
#5 0x0062d8e4 in wxMacCFStringHolder::wxMacCFStringHolder(wxString const&, wxFontEncoding) (this=0xbfffe5b0, str=@0xbd45ab4, encoding=wxFONTENCODING_DEFAULT) at ../wxWidgets/include/wx/mac/corefoundation/cfstring.h:46
#6 0x002941f0 in wxStaticText::SetLabel(wxString const&) (this=0xbd45940, st=@0xbfffe640) at ../wxWidgets/src/mac/carbon/stattext.cpp:94
#7 0x00158264 in CamuleDlg::AddLogLine(bool, wxString const&) (this=0x903c000, addtostatusbar=true, line=@0xbfffe87c) at amuleDlg.cpp:517
Some poking around at data:
(gdb) frame 3
#3 0x002d13b8 in wxMacCFStringHolder::Assign(wxString const&, wxFontEncoding) (this=0xbfffe5b0, st=@0xbd45ab4, encoding=wxFONTENCODING_DEFAULT) at ../wxWidgets/src/mac/corefoundation/cfstring.cpp:645
645 m_cfs = CFStringCreateWithCharacters( kCFAllocatorDefault ,
(gdb) list
640 #else
641 wxMBConvUTF16BE converter ;
642 size_t unicharlen = converter.WC2MB( NULL , str.wc_str() , 0 ) ;
643 UniChar *unibuf = new UniChar[ unicharlen / sizeof(UniChar) + 1 ] ;
644 converter.WC2MB( (char*)unibuf , str.wc_str() , unicharlen ) ;
645 m_cfs = CFStringCreateWithCharacters( kCFAllocatorDefault ,
646 unibuf , unicharlen / sizeof(UniChar) ) ;
647 delete[] unibuf ;
648 #endif
649 #else // not wxUSE_UNICODE
(gdb) print (long)unicharlen
$2 = -1
(gdb) print str
$3 = {
= {
static npos = 4294967295,
m_pchData = 0xb7d66ec
}, }
(gdb) print str.GetStringData()
$4 = (wxStringData *) 0xb7d66e0
(gdb) print *$4
$5 = {
nRefs = 0,
nDataLength = 0,
nAllocLength = 10
}
(gdb) print (char[10])str.m_pchData
$6 = "\v}f?????\000T"
(gdb) print (wchar_t[10])str.m_pchData
$7 = {192767724, -1, 5512476, 1, 8512400, 4841728, -1073748576, 0, -1, 192551136}
(gdb) print str.wc_str()
$8 = (const wxChar *) 0xb7d66ec
(gdb) print (*$8)@10
$9 = {1, 12, 19, 101, 77, 117, 108, 101, 32, 118}
(gdb) print str.c_str()
$11 = (const wxChar *) 0xb7d66ec
(gdb) print unibuf
$12 = (UniChar *) 0xb7a18e0
(gdb) print unicharlen / sizeof(UniChar) + 1
$13 = 2147483648
It looks like the fix might be as simple as failing out when unicharlen == -1. Although I'm not sure that wc_str() is returning an array with sensible values. I suppose we should actually fail out when str.IsEmpty() before ever invoking the converter. I just tested to make sure I was interpreting the wxStringData correctly:(gdb) print str.IsEmpty()
$16 = trueYup, it's empty. I'm off to submit a patch to wxMac.
