Last week I was having a pretty serious problem with wxPython on the Macintosh. The following block of code in wxPython is just plain wrong and after a few hours of operations the m_waiters array would be corrupted because of multiple threads contending for the memory.

If you're running wxPython 2.5.1.5, seriously considering patching your library as per these instructions.

while ( m_owner != kNoThreadID && m_owner != current)
{
 m_waiters.Add(current);
 ::SetThreadStateEndCritical(kCurrentThreadID, kStoppedThreadState, m_owner);
 ::ThreadBeginCritical();
}

It should read (as far as I can tell)

while ( m_owner != kNoThreadID && m_owner != current)
{
 ::SetThreadStateEndCritical(kCurrentThreadID, kStoppedThreadState, m_owner);
 m_waiters.Add(current);
 ::ThreadBeginCritical();
}

I knew that rebuilding wxPython libraries from scratch could end up being more trouble than it's worth, so I decided to take a different approach. Last Friday night I did an extending hacking session on wxPython's libraries. I downloaded Apple's Xcode developer tools and disassembled (using objdump) the broken module. Looking at the PowerPC opcodes, I figured one little tweak would do the trick. I needed to change this:

675f8:   38 a0 00 01     li      r5,1
675fc:   4b fb 17 39     bl      [wxBaseArrayLong::Add]

67600:   38 60 00 01     li      r3,1
67604:   38 80 00 01     li      r4,1
67608:   80 be 00 00     lwz     r5,0(r30)
6760c:   48 01 30 69     bl      [::SetThreadStateEndCritical]

67610:   48 01 30 a5     bl      [::ThreadBeginCritical]

to this:

67610:   48 01 30 a5     bl      [::ThreadBeginCritical]

675f8:   38 a0 00 01     li      r5,1
675fc:   4b fb 17 39     bl      [wxBaseArrayLong::Add]

67600:   38 60 00 01     li      r3,1
67604:   38 80 00 01     li      r4,1
67608:   80 be 00 00     lwz     r5,0(r30)
6760c:   48 01 30 69     bl      [::SetThreadStateEndCritical]

Note that I had to figure out those symbolic names — the objdump program didn't do that for me. Here's a Python program to make the fix:

old_data = [
 0x38, 0xa0, 0x00, 0x01, 
 0x4b, 0xfb, 0x17, 0x39,  # wxArrayLong::Add
 0x38, 0x60, 0x00, 0x01,
 0x38, 0x80, 0x00, 0x01,
 0x80, 0xbe, 0x00, 0x00,
 0x48, 0x01, 0x30, 0x69,  # ::SetThreadStateEndCritical
 0x48, 0x01, 0x30, 0xa5,  # ::ThreadBeginCritical
]

new_data = [
 0x48, 0x01, 0x30, 0xa5,  # ::ThreadBeginCritical
 0x38, 0xa0, 0x00, 0x01, 
 0x4b, 0xfb, 0x17, 0x39,  # wxArrayLong::Add
 0x38, 0x60, 0x00, 0x01,
 0x38, 0x80, 0x00, 0x01,
 0x80, 0xbe, 0x00, 0x00,
 0x48, 0x01, 0x30, 0x69,  # ::SetThreadStateEndCritical
]

fio = open('build/Jaeger.app/Contents/Frameworks/libwx_base_carbond-2.5.1.0.0.dylib', 'rb+')
fio.seek(start)

f_in = fio.read(len(old_data))

for i in xrange(len(old_data)):
 if old_data[i] != ord(f_in[i]):
  print >> sys.stderr, "data did not match"
  print >> sys.stderr, "%d: %02x %02x" % ( i, old_data[i], ord(f_in[i]) )
  sys.exit(1)

fio.seek(start)

for i in xrange(len(new_data)):
 fio.write(chr(new_data[i]))
 
fio.close()

There was one other piece of code causing a crash in Jäger. My advice — never never ever try to modify wxPython objects from outside their thread: it ain't ever going to work.