Hello Du Yunfen,
one thing beforehand: Great to see you think I'm the right person for
this kind of problem :), but actually this touches code areas which I
barely know. Thus, I think this discussion is best continued at
[EMAIL PROTECTED] I send this mail to the list, and would like to ask
you to reply to the list, too.
Further comments inline (and full quote for the new readers).
> Hi, Mr Schönheit
>
> It's still on the issue mentioned last time.
> the operation steps as follows:
>
> .create a new writer(or base ,calc ,draw ...).
> .click view->datasource.
> .choose a local datasource of nodes ,connect.
> .activate the context.
> .switch to another input method .
>
> then the application will freeze.We had Tracked the threads and I found
> when it is freezed, the application is still
> activated in the thread *[3640]rtl_cache_wsupdate_all* and always in a
> cycle which is in ../sal/source/rtl/alloc_cache.c :
> rtl_cache_wsupdate_all (void * arg)
> { ......
> while (!g_cache_list.m_update_done)
> { ......
> }
> },
> and
This doesn't tell me anything, sorry.
> in the thread *[3888]desktop::GetURL_Impl*, the programme run to
> ERROR_MORE_DATA in osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) which
> in ../sal/osl/w32/pipe.c.
>
> So I want to know what are modules( *sal* and *vos* ) used to achieve
> and the possible contact between switch the input method and connected
> a local datasource ?
I don't know ... sal is the "system abstraction layer", vos is some
older code for low-level system independent stuff, where nearly
everything in vos has a modern replacement in sal or osl.
> Thanks.
> Best Wishes.
>
> duyunfen
>
>
> ps: the threads:
>
> [3100]WinMain
> ntdll.dll!7c92eb94()
> user32.dll!77d194be()
> user32.dll!77d1b42d()
> user32.dll!77d184fc()
> user32.dll!77d185a4()
> user32.dll!77d1b3f9()
> user32.dll!77d1b393()
>> vcl680mi.dll!SalFrameWndProcW(HWND__ * hWnd=0x001008e4, unsigned int
> nMsg=80, unsigned int wParam=1, long lParam=-534640636) Line 6060 + 0x16 C++
> user32.dll!77d18734()
> user32.dll!77d18816()
> imm32.dll!7630e489()
> user32.dll!77d1f805()
> user32.dll!77d189cd()
> user32.dll!77d18a10()
> vcl680mi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x0101f698) Line
> 200 + 0xa C++
> vcl680mi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x0101f698) Line 716 +
> 0x9 C++
> vcl680mi.dll!ImplSalYield(unsigned char bWait='', unsigned char
> bHandleAllCurrentEvents=0) Line 746 + 0x9 C++
> vcl680mi.dll!WinSalInstance::Yield(bool bWait=true, bool
> bHandleAllCurrentEvents=false) Line 791 + 0xd C++
> vcl680mi.dll!Application::Yield(bool bAllEvents=false) Line 554 C++
> vcl680mi.dll!Application::Execute() Line 516 + 0x7 C++
> soffice.exe!desktop::Desktop::Main() Line 1803 C++
> vcl680mi.dll!ImplSVMain() Line 255 C++
> vcl680mi.dll!SVMain() Line 296 C++
> soffice.exe!sal_main(int __formal=1, int __formal=1) Line 82 C++
> soffice.exe!WinMain(void * _hinst=0x00400000, void * _dummy=0x00000000,
> char * _cmdline=0x00051f0a, int _nshow=1) Line 74 + 0x39 C++
> soffice.exe!WinMainCRTStartup() Line 390 + 0x1b C
> kernel32.dll!7c816fd7()
> ntdll.dll!7c935b4f()
This thread *might* be part of the problem, since it seems that
dispatching a message blocks for whatever reasons. However, I don't know
enough about that kind of stuff.
>
> [3640]rtl_cache_wsupdate_all
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> kernel32.dll!7c802532()
>> sal3.dll!rtl_cache_wsupdate_wait(unsigned int seconds=10) Line 1450 C
> sal3.dll!rtl_cache_wsupdate_all(void * arg=0x0000000a) Line 1547 + 0x9 C
> kernel32.dll!7c80b683()
>
> [3956]oslWorkerWrapperFunction
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> ntdll.dll!7c946abe()
> kernel32.dll!7c802532()
>> sal3.dll!osl_waitCondition(void * Condition=0x00000f48, const
> TimeValue * pTimeout=0x03d7ff54) Line 112 + 0xe C
> vos3MSC.dll!vos::OCondition::wait(const TimeValue * pTimeout=0x03d7ff54)
> Line 75 + 0x10 C++
> vos3MSC.dll!vos::OTimerManager::run() Line 492 + 0x14 C++
> vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02de6eb4) Line
> 50 + 0xc C++
> sal3.dll!oslWorkerWrapperFunction(void * pData=0x03313eb0) Line 81 + 0xd C
> msvcr71.dll!63fb9565()
> ntdll.dll!7c946abe()
> kernel32.dll!7c80b683()
> ntdll.dll!7c946abe()
>
> [3888]desktop::GetURL_Impl
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> ntdll.dll!7c92fb6c()
> ntdll.dll!7c92da69()
> kernel32.dll!7c802532()
> kernel32.dll!7c831608()
>> sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) Line 418 + 0x17 C
> vos3MSC.dll!vos::OPipe::accept(vos::OStreamPipe & Connection={...}) Line
> 232 + 0xf C++
> soffice.exe!desktop::OfficeIPCThread::run() Line 575 + 0x13 C++
> vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02e0a804) Line
> 50 + 0xc C++
> sal3.dll!oslWorkerWrapperFunction(void * pData=0x0330e778) Line 81 + 0xd C
> msvcr71.dll!63fb9565()
> kernel32.dll!7c80b683()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
> 0xd C++
> c0c40000()
> soffice.exe!desktop::GetURL_Impl(const String & rName=) Line 2786 + 0xd C++
This thread's stack looks suspicious - too many GetURL_Impl instances
here, I somehow think this stack is corrupted. Besides this, I think
this thread might also be a part of the freeze.
>
> [3096]Win32 Thread
> [476]Win32 Thread
>
> [3444]oslWorkerWrapperFunction
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> kernel32.dll!7c802532()
> nspr4.dll!3001886c()
> nspr4.dll!300149fc()
> nspr4.dll!30014b23()
> nspr4.dll!30014516()
> mozabdrv2.dll!MNS_XPCOM_EventLoop() + 0xd0 C++
> mozabdrv2.dll!_MNS_Mozilla_UI_Thread() + 0x2b C++
>> sal3.dll!oslWorkerWrapperFunction(void * pData=0x06151d50) Line 81 + 0xd C
> msvcr71.dll!63fb9565()
> kernel32.dll!7c80b683()
This thread might also be part of the problem. When accessing the
Mozilla code shipped with OOo (for access to Mozilla and other address
books), all this access runs in a dedicated thread, for technical
reasons. 3444 looks as if it is exactly this thread. Might be
interesting to know at which line in MNS_XPCOM_EventLoop the thread is
stuck here.
To check whether this is code is part of the problem, you might try to
simply remove te mozabdrv2.dll from your installation. This will prevent
it being loaded, without problems at the UI (only various address books
are not available then).
> [3564]Win32 Thread
> [3924]Win32 Thread
> [1832]Win32 Thread
> [1188]Win32 Thread
> [980]Win32 Thread
> [3332]Win32 Thread
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Sitz der Gesellschaft: -
- Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten -
- Amtsgericht München: HRB 161028 -
- Geschäftsführer: Wolfgang Engels, Dr. Roland Bömer -
- Vorsitzender des Aufsichtsrates: Martin Häring -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
