libmscordbi.so calls into libvsbaseservices.so's PAL, causing corruption

[gregg-miskelly]

Steps to reproduce

On Linux --
1: Build debug build of clrdbg
2: Build debuggee --

cd ~
mkdir clicon
cd clicon
dotnet new
dotnet build

3: Launch debuggee

./clrdbg --interpreter=mi
-file-exec-and-symbols dotnet
-environment-cd ~/clicon
-exec-arguments bin/Debug/netcoreapp1.0/clicon.dll
-exec-run

4: After stopping on entry point, stop using -gdbexit

Expected behavior:

Cleanly shutdown

Actual behavior:

ASSERT FAILED: "\"Operation failed\""
    Expression: 0
    Location:   line 111 in /home/greggm/clrdbg/src/debugger/concord/Dispatcher/NoRemotingDll/../XapiWorkerThreadTask.h
    Function:   SetResult
terminate called after throwing an instance of 'XapiException'
Aborted (core dumped)

The issue is that CloseHandle was already called by mscordbi here:

libvsbaseservices.so!CloseHandle(HANDLE hObject) Line 287   C++
libmscordbi.so![Unknown/Just-In-Time compiled code] 
libvsdebugeng.impl.so!CComObjectPtr<IMetaDataImport2>::~CComObjectPtr(CComObjectPtr<IMetaDataImport2> * this) Line 168  C++
libvsdebugeng.impl.so!ManagedDM::CDMModule::~CDMModule(ManagedDM::CDMModule * this) Line 25 C++
libvsdebugeng.impl.so!ManagedDM::CDMModule::~CDMModule(ManagedDM::CDMModule * this) Line 24 C++
libvsdebugeng.impl.so!non-virtual thunk to ManagedDM::CDMModule::~CDMModule()() Line 25 C++
libvsdebugeng.impl.so!CRefCount::Release(CRefCount * this) Line 124 C++
libvsdebugeng.impl.so!ManagedDM::CDMModule::Release(ManagedDM::CDMModule * this) Line 40    C++
libvsdebugeng.so!dispatcher::DkmDataContainer::InvokeOnClose(dispatcher::XapiComponentInfo * pComponent, IUnknown * pDataItem, dispatcher::XapiComponentInfo ** ppComponent) Line 3381  C++
libvsdebugeng.so!dispatcher::DkmDataContainer::Empty(dispatcher::DkmDataContainer * pDataContainer, dispatcher::XapiComponentInfo ** ppComponent) Line 3353 C++
libvsdebugeng.so!dispatcher::DkmDataContainer::CollectionTermPhase2(dispatcher::DkmDataContainer * this, dispatcher::XapiThreadOperation * pOperation) Line 2989    C++
libvsdebugeng.so!dispatcher::CXapiPhase2ObjectQueue::FlushList(dispatcher::XapiThreadOperation * pOperation, ATL::CAtlList<dispatcher::DkmDataContainer*, ATL::CElementTraits<dispatcher::DkmDataContainer*> > * pList) Line 130    C++
libvsdebugeng.so!dispatcher::XapiCollectionTermPhase2Task::ExecuteTask(dispatcher::XapiCollectionTermPhase2Task * this, dispatcher::XapiThreadOperation * pMTAOperation) Line 27    C++
libvsdebugeng.so!dispatcher::XapiWorkerThread::ProcessSyncTask(dispatcher::XapiWorkerThreadSyncTask * pSyncTask, dispatcher::XapiThreadOperation * pOperation) Line 450 C++
libvsdebugeng.so!dispatcher::XapiWorkerThread::ThreadRoutine(dispatcher::XapiWorkerThread * this) Line 359  C++
libvsdebugeng.so!dispatcher::XapiWorkerThread::_ThreadRoutine(LPVOID pvThis) Line 311   C++
libvsbaseservices.so!CorUnix::CPalThread::ThreadEntry(void * pvParam) Line 1641 C++
libpthread.so.0!start_thread(void * arg) Line 312   C
libc.so.6!clone() Line 111  C++

[gregg-miskelly]

I believe the problem is that libmscordbi.so imports CloseHandle very generically:

> objdump -T /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/libmscordbi.so | grep CloseHandle
0000000000000000      DF *UND*  0000000000000000  V1.0        CloseHandle

Hopefully there is something with our versioning script that we can do to make sure that dbi binds to the DAC PAL instead.

[caslan]

@gregg-miskelly Shouldn't we close this now?

[gregg-miskelly]

Sounds good.

This was resolved with #498