Hi,
Looking at your code, I do see one interesting thing. Both thread 3 and thread 4 (the crashed thread) are both in the same function. So if that code is not threadsafe or reentrant then it could cause a serious problem (a problem that might bite you and not me randomly).
Here for example in Thread 3:
9 com.valloric.Sigil.app 0x000a8d00 Utility::URLDecodePath(QString const&) + 48
10 com.valloric.Sigil.app 0x000134bb PerformHTMLUpdates::UpdateReferenceInNode(xercesc_ 3_1:OMElement*) + 555
11 com.valloric.Sigil.app 0x0001480e QtConcurrent::VoidStoredMemberFunctionPointerCall1 <void, PerformHTMLUpdates, xercesc_3_1:
and here in the crashed thread (Thread 4):
0 com.valloric.Sigil.app 0x0016dbac xercesc_3_1::BaseRefVectorOf<xercesc_3_1:OMNode> ::addElement(xercesc_3_1:OMNode*) + 12
1 com.valloric.Sigil.app 0x0019655a xercesc_3_1:OMTextImpl::release() + 154
2 com.valloric.Sigil.app 0x0015e624 xercesc_3_1:OMAttrImpl::setValue(unsigned short const*) + 132
3 com.valloric.Sigil.app 0x000138b8 PerformHTMLUpdates::UpdateReferenceInNode(xercesc_ 3_1:OMElement*) + 1576
4 com.valloric.Sigil.app 0x0001480e QtConcurrent::VoidStoredMemberFunctionPointerCall1 <void, PerformHTMLUpdates, xercesc_3_1:
So the question becomes is this piece of code thread-safe (which is really hard to know sometimes with c++ code). Perhaps a lock is needed on xc:
OMElement (on the entire tree or just that node) to prevent one part of the tree from being changed by one thread while the same part of the tree is being changed in another thread?
Hard to say without knowing what the underlying code actually does. Perhaps it grabs all of the locks it needs and something else is the problem. But it is at least worth exploring.
Hope this helps,
KevinH