Hmm...yeah, I've been looking at the crash logs, but all that I've seen so far (in Sherlock's case) is that there's a consistent problem in the thread that's handling some kind of security, or at least digest-like data verification.
I'm still working on it. This is basically what happens everytime:
Thread 2 Crashed:
#0 0x900741f0 in memmove
#1 0x92ba3828 in shsUpdate
#2 0x92bd7a0c in SHA1Object::digestUpdate(void const*, unsigned long)
#3 0x92cd94e4 in Security::CSPFullPluginSession::VerifyDataUpdate(unsigned long long, Security::CssmData const*, unsigned long)
#4 0x92cd8ed0 in Security::CSPFullPluginSession::VerifyData(unsigned long long, Security::Context const&, Security::CssmData const*, unsigned long, unsigned long, Security::CssmData const&)
#5 0x92c1bce8 in cssm_VerifyData(unsigned long, unsigned long long, cssm_context const*, cssm_data const*, unsigned long, unsigned long, cssm_data const*)
#6 0x92bf5f5c in CSSM_VerifyData
#7 0x92ca7b84 in Security::CssmClient::Verify::verify(Security::CssmData const*, unsigned long, Security::CssmData const&)
#8 0x9417b3a4 in VerifySmallDownload
#9 0x9417af44 in VerifyData
#10 0x94158ddc in ResourceDidFinishLoadingCallBack
#11 0x93fac610 in -[IFURLHandle(IFURLHandleClassInternal) _notifyClientsDidFinishLoading]
#12 0x93fac270 in -[IFURLHandle(IFURLHandleClassInternal) _sendCallbacks]
#13 0x90149414 in __CFRunLoopDoSources0
#14 0x901487f8 in __CFRunLoopRun
#15 0x90180f58 in CFRunLoopRunSpecific
#16 0x90148240 in CFRunLoopRun
#17 0x9415c2ec in SEMessageHandlerRun
#18 0x9415c104 in SEEventLoopRun
#19 0x9415db4c in HTTPRequestEventLoopEntry
#20 0x9415be98 in ThreadEntryInternal
#21 0x90020d28 in _pthread_body