segfault in CMPI_ThreadContext::add

We're currently using Pegasus 2.7.2 (yes, I realize it's very old), and have seen an occasional (rare but fatal) core at startup in CMPI_ThreadContext. It happens when the first request comes in (in this particular trace, a request to delete an indication poller) - our provider gets loaded, and the DeleteInstance (for this particular provider) method is called with the CMPIObjectPath being passed in by the ProviderManagerService. After initializing a CMPIStatus object, we turn around and call CMGetClassName with the CMPIObjectPath object that was passed in, along with that CMPIStatus object - cimserver dies somewhere in CMPI_ThreadContext. Here's the stack trace:

#0  0xf52d5179 in Pegasus::CMPI_ThreadContext::add () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#1  0xf52d540a in Pegasus::CMPI_ThreadContext::addObject () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#2  0xf52bfcd2 in Pegasus::CMPI_Object::CMPI_Object () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#3  0xf52d512c in Pegasus::string2CMPIString () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#4  0xf52cf92f in refGetClassName () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#5  0xf542fbeb in Pivot3_CommonIndicationProviderDeleteInstance (mi=0xf5438240, ctx=0xf5c66dc0, rslt=0xf5c66d90,
    cop=0xf5c66de8) at cmpi_Pivot3_CommonIndicationProvider.c:335
#6  0xf5290cb9 in Pegasus::CMPIProviderManager::handleDeleteInstanceRequest ()
   from /pivot3/pegasus/lib/libCMPIProviderManager.so
#7  0xf52a6493 in Pegasus::CMPIProviderManager::processMessage () from /pivot3/pegasus/lib/libCMPIProviderManager.so
#8  0xf7cb82bb in Pegasus::BasicProviderManagerRouter::processMessage () from /pivot3/pegasus/lib/libpegpmservice.so.1
#9  0xf7cb2295 in Pegasus::ProviderManagerService::_processMessage () from /pivot3/pegasus/lib/libpegpmservice.so.1
#10 0xf7cb3a08 in Pegasus::ProviderManagerService::handleCimRequest () from /pivot3/pegasus/lib/libpegpmservice.so.1
#11 0xf7cb4b78 in Pegasus::ProviderManagerService::handleCimOperation () from /pivot3/pegasus/lib/libpegpmservice.so.1
#12 0xf7b8165b in Pegasus::ThreadPool::_loop () from /pivot3/pegasus/lib/libpegcommon.so.1
#13 0xf7b80425 in _start_wrapper () from /pivot3/pegasus/lib/libpegcommon.so.1
#14 0xf79fd3ba in start_thread () from /lib/libpthread.so.0
#15 0xf7814e2e in clone () from /lib/libc.so.6

Any ideas on what might be going on? The CMPI_ThreadContext::add method just calls ENQ_TOP_LIST, which looks like it's adding the CMPIObjectPath object to a linked list - I don't know if something isn't being initialized correctly (i.e. if the request comes in before cimserver is done initializing) or what. But the next time cimserver runs, everything works just fine. In fact, we've only seen this particular core maybe 2 or 3 times - through different providers but in the same lower level calls down in Pegasus. 

Thanks in advance!

Wendy