<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - CppUnitTester hang on windows machine"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=121228#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - CppUnitTester hang on windows machine"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=121228">bug 121228</a>
from <span class="vcard"><a class="email" href="mailto:markus.mohrhard@googlemail.com" title="Markus Mohrhard <markus.mohrhard@googlemail.com>"> <span class="fn">Markus Mohrhard</span></a>
</span></b>
<pre>(In reply to Juergen Funk (CIB) from <a href="show_bug.cgi?id=121228#c4">comment #4</a>)
<span class="quote">> That is the first thread:
>
> win32u.dll!NtUserGetMessage()
> user32.dll!GetMessageW()
> sysdtrans.dll!CMtaOleClipboard::run() at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\mtaoleclipb.cxx(711)
> sysdtrans.dll!CMtaOleClipboard::oleThreadProc(void *
> pParam=0x000001f7204b0928) at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\mtaoleclipb.cxx(733)
> ucrtbased.dll!invoke_thread_procedure(unsigned int(*)(void *)
> procedure=0x00007ff9c2bcbff0, void * const context=0x000001f7204b0928) t
> minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(92)
> ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void *
> const parameter=0x000001f720769d60) at
> minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(115)
> kernel32.dll!BaseThreadInitThunk()
> ntdll.dll!RtlUserThreadStart()
>
>
>
>
>
> And that is the second one
>
> ntdll.dll!RtlUnwindEx()
> ntdll.dll!__C_specific_handler()
> rpcrt4.dll!__GSHandlerCheck_SEH()
> ntdll.dll!RtlpExecuteHandlerForException()
> ntdll.dll!RtlDispatchException()
> ntdll.dll!KiUserExceptionDispatch()
> KernelBase.dll!RaiseException()
> rpcrt4.dll!RpcpRaiseException()
> rpcrt4.dll!RpcRaiseException()
> combase.dll!NdrExtpProxySendReceive(void * pThis=0x0000000000000003,
> _MIDL_STUB_MESSAGE * pStubMsg=0x00000037e78ff100) at
> onecore\com\combase\ndr\ndrole\proxy.cxx(1971)
> rpcrt4.dll!NdrpClientCall3()
> rpcrt4.dll!NdrClientCall3()
> [Inline Frame] combase.dll!IEnumFORMATETC_RemoteNext_Proxy(IEnumFORMATETC *)
> at onecore\com\combase\proxy\idl\daytona\objfre\amd64\mega_p.c(1254)
> combase.dll!IEnumFORMATETC_Next_Proxy(IEnumFORMATETC * This, unsigned long
> celt, tagFORMATETC * rgelt, unsigned long * pceltFetched=0x0000000000000000)
> at onecore\com\combase\proxy\proxy\call_as.c(1680)
> sysdtrans.dll!CDOTransferable::initFlavorList() at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\dtobj\dotransferable.cxx(284)
> sysdtrans.dll!CDOTransferable::create(const
> com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> &
> rxContext={...}, sal::systools::COMReference<IDataObject>
> pIDataObject={...}) at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\dtobj\dotransferable.cxx(181)
> sysdtrans.dll!CWinClipbImpl::getContents() at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\winclipbimpl.cxx(101)
> sysdtrans.dll!CWinClipboard::notifyAllClipboardListener() at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\winclipboard.cxx(180)
> sysdtrans.dll!CWinClipbImpl::onClipboardContentChanged() at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\winclipbimpl.cxx(178)
> sysdtrans.dll!CMtaOleClipboard::clipboardChangedNotifierThreadProc(void *
> pParam=0x000001f7204b0928) at
> d:\src\lo\lhm\lo6.1\dtrans\source\win32\clipb\mtaoleclipb.cxx(765)
> ucrtbased.dll!invoke_thread_procedure(unsigned int(*)(void *)
> procedure=0x00007ff9c2bcb150, void * const context=0x000001f7204b0928) at
> minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(92)
> ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void *
> const parameter=0x000001f720768c50) at
> minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(115)
> kernel32.dll!BaseThreadInitThunk()
> ntdll.dll!RtlUserThreadStart()
>
> I think the other threads are unimportant (wsupdate, GdiPlus, 4x
> TppWorkerThread)
>
> Thanks for help</span >
I absolutely can not understand how the second thread can be stuck. The thread
is in the windows API inside calls that look like throwing a SEH exception. IF
none of the COM methods called are actually catching SEH this should
theoretically result in a crash (we no longer handle SEH as normal C++
exceptions and therefore should not catch them).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>