When sipXtapi tests are run (sipXcallLib/src/test/tapi/sandbox), segmentation faults happen in random locations.
I wanted to isolate this problem to something small, so I went through each test individually and came up with a crashing test that is relatively small compared to the other crashing tests.

To isolate this test, edit sipXcallLib/src/test/tapi/sipXtapiTest.h and set all test groups to 0 to prevent running, and comment out every test in the TEST_CALL group except testSendInfo. When run by itself, I have determined that this will crash roughly 3 out of every 25 runs, producing the following result:

--------------- TESTSUITE PROGRAM OUTPUT ----------------
kkyzivat@yubaba:~/builds/tree-sipXtapi/sipXcallLib/src/test/tapi$ ./testsuite
.
testSendInfo ( 1 of 3)MpRtpInputAudioConnection::handleMessage MPRM_STOP_RECEIVE_RTP
MpRtpInputAudioConnection::handleMessage MPRM_STOP_RECEIVE_RTP
Segmentation fault (core dumped)
--------------- END TESTSUITE PROGRAM OUTPUT ----------------

and has the following stack trace:

---------------- GDB COREFILE STACKTRACE -----------------
Core was generated by `/home/kkyzivat/builds/tree-sipXtapi/sipXcallLib/src/test/tapi/.libs/lt-testsuit'.
Program terminated with signal 11, Segmentation fault.
#0 0x080573a1 in OsLock (this=0xb30c0478, rSemaphore=@0x1c4)
    at /home/kkyzivat/builds/tree-sipXtapi/sipXcallLib/../sipXportLib/include/os/OsLock.h:61
61 : mrSemaphore(rSemaphore) { rSemaphore.acquire(); };
(gdb) bt
#0 0x080573a1 in OsLock (this=0xb30c0478, rSemaphore=@0x1c4)
    at /home/kkyzivat/builds/tree-sipXtapi/sipXcallLib/../sipXportLib/include/os/OsLock.h:61
#1 0xb7bb3dee in UtlListIterator (this=0xb30c04f4, list=@0x1c0)
    at utl/UtlListIterator.cpp:47
#2 0xb7bb4e7a in UtlSListIterator (this=0xb30c04f4, list=@0x1c0)
    at utl/UtlSListIterator.cpp:30
#3 0xb7cb8970 in SdpBody (this=0x83785d8, rSdpBody=@0x834f048)
    at net/SdpBody.cpp:103
#4 0xb7c87a4e in HttpBody::copyBody (sourceBody=@0x834f048)
    at net/HttpBody.cpp:268
#5 0xb7c9243e in HttpMessage (this=0x83790b0, rHttpMessage=@0x832f288)
    at net/HttpMessage.cpp:138
#6 0xb7cff3f9 in SipMessage (this=0x83790b0, rSipMessage=@0x832f288)
    at net/SipMessage.cpp:100
#7 0xb7d40d7d in SipTransaction::recurseDnsSrvChildren (this=0x837b950,
    userAgent=@0x82b0c38, transactionList=@0x82b1450, pTransport=0x0)
    at net/SipTransaction.cpp:2602
#8 0xb7d41f42 in SipTransaction::handleOutgoing (this=0x837b950,
    outgoingMessage=@0xb30c21ec, userAgent=@0x82b0c38,
    transactionList=@0x82b1450, relationship=MESSAGE_REQUEST, pTransport=0x0)
    at net/SipTransaction.cpp:602
#9 0xb7d5aa86 in SipUserAgent::send (this=0x82b0c38, message=@0xb30c21ec,
---Type <return> to continue, or q <return> to quit---
    responseListener=0x82b0f10, responseListenerData=0x0, pTransport=0x0)
    at net/SipUserAgent.cpp:969
#10 0xb7b04be3 in SipConnection::send (this=0x832b060, message=@0xb30c21ec,
    responseListener=0x82b0f10, responseListenerData=0x0,
    bUseSendToTransportType=0) at cp/SipConnection.cpp:6994
#11 0xb7b18ef1 in SipConnection::sendInfo (this=0x832b060,
    contentType=@0xb30c2b30, sContent=@0xb30c2abc) at cp/SipConnection.cpp:1064
#12 0xb7afbfe6 in CpPeerCall::handleSendInfo (this=0x8327f88,
    pEventMessage=0x835a400) at cp/CpPeerCall.cpp:2562
#13 0xb7b0063f in CpPeerCall::handleCallMessage (this=0x8327f88,
    eventMessage=@0x835a400) at cp/CpPeerCall.cpp:2129
#14 0xb7ae889d in CpCall::handleMessage (this=0x8327f88,
    eventMessage=@0x835a400) at cp/CpCall.cpp:606
#15 0xb7bec5eb in OsServerTask::run (this=0x8327f88, pArg=0x0)
    at os/OsServerTask.cpp:163
#16 0xb7c0e770 in OsTaskLinux::taskEntry (arg=0x8327f88)
    at os/linux/OsTaskLinux.cpp:713
#17 0xb780731b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb791257e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
---------------- END GDB COREFILE STACKTRACE -----------------


This appears to be a memory corruption problem, so this particular stack trace may not be extremely helpful.